2.6.20.17 -stable review
Subsystems (31)
cover 2.6.20.17 -stable review
This is the start of the review cycle for the stable 2.6.20.17 kernel release. This version catches up with 2.6.22.4, and 58 patches will be posted as a response to this message.
The following security issues are solved :
CVE-2007-3105
CVE-2007-3848
CVE-2007-3851
The rolled up patch can be found here :
ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gz
Responses should be made by August 24, 2007, 19:00:00 UTC. Anything received after that time might be too late.
Thanks,
Willy
PATCH 1/58 Fix IPCOMP crashes.
[XFRM]: Fix crash introduced by struct dst_entry reordering
XFRM expects xfrm_dst->u.next to be same pointer as dst->next, which was broken by the dst_entry reordering in commit 1e19e02c~, causing an oops in xfrm_bundle_ok when walking the bundle upwards.
Kill xfrm_dst->u.next and change the only user to use dst->next instead.
--- include/net/xfrm.h | 1 - net/xfrm/xfrm_policy.c | 2 +- 2 files changed, 1 insertions(+), 2 deletions(-)
include/net/xfrm.h +0 -1
@@ -561,7 +561,6 @@ static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ctstruct xfrm_dst {union { -struct xfrm_dst *next;struct dst_entry dst;struct rtable rt;struct rt6_info rt6;
net/xfrm/xfrm_policy.c +1 -1
@@ -1971,7 +1971,7 @@ int xfrm_bundle_ok(struct xfrm_policy *pol, struct xfrm_dst *first,if (last == first)break ; - last = last->u.next; + last = (struct xfrm_dst *)last->u.dst.next; last->child_mtu_cached = mtu; }
Signature · 3 lines
1.5.2.5 --
PATCH 3/58 SCTP scope_id handling fix
In reply to Willy TarreauSCTP: Add scope_id validation for link-local binds
SCTP currently permits users to bind to link-local addresses, but doesn't verify that the scope id specified at bind matches the interface that the address is configured on. It was report that this can hang a system.
--- net/sctp/ipv6.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
net/sctp/ipv6.c +4 -0
@@ -874,6 +874,10 @@ static int sctp_inet6_send_verify(struct sctp_sock *opt, union sctp_addr *addr) dev =dev_get_by_index (addr->v6.sin6_scope_id);if (!dev)return 0 ; +if (!ipv6_chk_addr (&addr->v6.sin6_addr, dev,0 )) { +dev_put (dev); +return 0 ; + }dev_put (dev); } af = opt->pf->af;
Signature · 3 lines
1.5.2.5 --
PATCH 4/58 gen estimator timer unload race
In reply to Willy Tarreau[NET]: Fix gen_estimator timer removal race
As noticed by Jarek Poplawski <[email protected]>, the timer removal in gen_kill_estimator races with the timer function rearming the timer.
Check whether the timer list is empty before rearming the timer in the timer function to fix this.
--- net/core/gen_estimator.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
net/core/gen_estimator.c +2 -1
@@ -128,7 +128,8 @@ static void est_timer(unsigned long arg)spin_unlock (e->stats_lock); } -mod_timer (&elist[idx].timer, jiffies + ((HZ <<idx)/4 )); +if (elist[idx].list !=NULL ) +mod_timer (&elist[idx].timer, jiffies + ((HZ <<idx)/4 ));read_unlock (&est_lock); }
Signature · 3 lines
1.5.2.5 --
PATCH 5/58 gen estimator deadlock fix
In reply to Willy Tarreau[NET]: gen_estimator deadlock fix
-Fixes ABBA deadlock noted by Patrick McHardy <[email protected]>:
Quoted 7 lines
There is at least one ABBA deadlock,
est_timer()does:read_lock(&est_lock)spin_lock(e->stats_lock)(which isdev->queue_lock)and
qdisc_destroycallshtb_destroyunderdev->queue_lock, which callshtb_destroy_class, thengen_kill_estimatorand thiswrite_locksest_lock.
To fix the ABBA deadlock the rate estimators are now kept on an rcu list.
-The est_lock changes the use from protecting the list to protecting the update to the 'bstat' pointer in order to avoid NULL dereferencing.
-The 'interval' member of the gen_estimator structure removed as it is not needed.
--- net/core/gen_estimator.c | 81 ++++++++++++++++++++++++++++------------------ 1 files changed, 49 insertions(+), 32 deletions(-)
net/core/gen_estimator.c +49 -32
@@ -79,27 +79,27 @@struct gen_estimator { -struct gen_estimator *next; +struct list_head list;struct gnet_stats_basic *bstats;struct gnet_stats_rate_est *rate_est;spinlock_t *stats_lock; -unsigned interval;int ewma_log;u64 last_bytes;u32 last_packets;u32 avpps;u32 avbps; +struct rcu_head e_rcu; };struct gen_estimator_head {struct timer_list timer; -struct gen_estimator *list; +struct list_head list; };static struct gen_estimator_head elist[EST_MAX_INTERVAL +1 ]; -/* Estimator array lock */ +/* Protects against NULL dereference */ static DEFINE_RWLOCK (est_lock);static void est_timer (unsigned long arg)
@@ -107,13 +107,17 @@ static void est_timer(unsigned long arg)int idx = (int )arg;struct gen_estimator *e; -read_lock (&est_lock); -for (e = elist[idx].list; e; e = e->next) { +rcu_read_lock (); +list_for_each_entry_rcu (e, &elist[idx].list, list) {u64 nbytes;u32 npackets;u32 rate;spin_lock (e->stats_lock); +read_lock (&est_lock); +if (e->bstats ==NULL ) + goto skip; + nbytes = e->bstats->bytes; npackets = e->bstats->packets; rate = (nbytes - e->last_bytes)<<(7 - idx);
@@ -125,12 +129,14 @@ static void est_timer(unsigned long arg) e->last_packets = npackets; e->avpps += ((long )rate - (long )e->avpps) >> e->ewma_log; e->rate_est->pps = (e->avpps+0x1FF )>>10 ; +skip: +read_unlock (&est_lock);spin_unlock (e->stats_lock); } -if (elist[idx].list !=NULL ) +if (!list_empty (&elist[idx].list))mod_timer (&elist[idx].timer, jiffies + ((HZ <<idx)/4 )); -read_unlock (&est_lock); +rcu_read_unlock (); }/**
@@ -147,12 +153,17 @@ static void est_timer(unsigned long arg)* &rate_est with the statistics lock grabed during this period. * * Returns 0 on success or a negative error code. +* +* NOTE: Called under rtnl_mutex */ int gen_new_estimator (struct gnet_stats_basic *bstats, -struct gnet_stats_rate_est *rate_est,spinlock_t *stats_lock,struct rtattr *opt) +struct gnet_stats_rate_est *rate_est, +spinlock_t *stats_lock, +struct rtattr *opt) {struct gen_estimator *est;struct gnet_estimator *parm =RTA_DATA (opt); +int idx;if (RTA_PAYLOAD (opt) <sizeof (*parm))return -EINVAL ;
@@ -164,7 +175,7 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,if (est ==NULL )return -ENOBUFS ; - est->interval = parm->interval +2 ; + idx = parm->interval +2 ; est->bstats = bstats; est->rate_est = rate_est; est->stats_lock = stats_lock;
@@ -174,20 +185,25 @@ int gen_new_estimator(struct gnet_stats_basic *bstats, est->last_packets = bstats->packets; est->avpps = rate_est->pps<<10 ; - est->next = elist[est->interval].list; -if (est->next ==NULL ) { -init_timer (&elist[est->interval].timer); - elist[est->interval].timer.data = est->interval; - elist[est->interval].timer.expires = jiffies + ((HZ <<est->interval)/4 ); - elist[est->interval].timer.function = est_timer; -add_timer (&elist[est->interval].timer); +if (!elist[idx].timer.function) { +INIT_LIST_HEAD (&elist[idx].list); +setup_timer (&elist[idx].timer, est_timer, idx); } -write_lock_bh (&est_lock); - elist[est->interval].list = est; -write_unlock_bh (&est_lock); + +if (list_empty (&elist[idx].list)) +mod_timer (&elist[idx].timer, jiffies + ((HZ <<idx)/4 )); + +list_add_rcu (&est->list, &elist[idx].list);return 0 ; } +static void __gen_kill_estimator (struct rcu_head *head) +{ +struct gen_estimator *e =container_of (head, + struct gen_estimator, e_rcu); +kfree (e); +} +/** * gen_kill_estimator - remove a rate estimator * @bstats: basic statistics
@@ -195,31 +211,32 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,* * Removes the rate estimator specified by &bstats and &rate_est * and deletes the timer. +* +* NOTE: Called under rtnl_mutex */ void gen_kill_estimator (struct gnet_stats_basic *bstats,struct gnet_stats_rate_est *rate_est) {int idx; -struct gen_estimator *est, **pest; +struct gen_estimator *e, *n;for (idx=0 ; idx <=EST_MAX_INTERVAL ; idx++) { -int killed =0 ; - pest = &elist[idx].list; -while ((est=*pest) !=NULL ) { -if (est->rate_est != rate_est || est->bstats != bstats) { - pest = &est->next; + +/* Skip non initialized indexes */ +if (!elist[idx].timer.function) +continue ; + +list_for_each_entry_safe (e, n, &elist[idx].list, list) { +if (e->rate_est != rate_est || e->bstats != bstats)continue ; - }write_lock_bh (&est_lock); - *pest = est->next; + e->bstats =NULL ;write_unlock_bh (&est_lock); -kfree (est); - killed++; +list_del_rcu (&e->list); +call_rcu (&e->e_rcu, __gen_kill_estimator); } -if (killed && elist[idx].list ==NULL ) -del_timer (&elist[idx].timer); } }
Signature · 3 lines
1.5.2.5 --
PATCH 7/58 Fix ipv6 link down handling.
In reply to Willy Tarreau[IPV6]: Call inet6addr_chain notifiers on link down
Currently if the link is brought down via ip link or ifconfig down, the inet6addr_chain notifiers are not called even though all the addresses are removed from the interface. This caused SCTP to add duplicate addresses to it's list.
--- net/ipv6/addrconf.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
net/ipv6/addrconf.c +1 -0
@@ -2451,6 +2451,7 @@ static int addrconf_ifdown(struct net_device *dev, int how)write_unlock_bh (&idev->lock);__ipv6_ifa_notify (RTM_DELADDR , ifa); +atomic_notifier_call_chain (&inet6addr_chain,NETDEV_DOWN , ifa);in6_ifa_put (ifa);write_lock_bh (&idev->lock);
Signature · 3 lines
1.5.2.5 --
PATCH 8/58 Netpoll leak
In reply to Willy Tarreau[NETPOLL]: Fix a leak-n-bug in netpoll_cleanup()
93ec2c723e3f8a216dde2899aeb85c648672bc6b applied excessive duct tape to the netpoll beast's netpoll_cleanup(), thus substituting one leak with another, and opening up a little buglet :-)
net_device->npinfo (netpoll_info) is a shared and refcounted object and cannot simply be set NULL the first time netpoll_cleanup() is called. Otherwise, further netpoll_cleanup()'s see np->dev->npinfo == NULL and become no-ops, thus leaking. And it's a bug too: the first call to netpoll_cleanup() would thus (annoyingly) "disable" other (still alive) netpolls too. Maybe nobody noticed this because netconsole (only user of netpoll) never supported multiple netpoll objects earlier.
This is a trivial and obvious one-line fixlet.
--- net/core/netpoll.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
net/core/netpoll.c +1 -1
@@ -776,7 +776,6 @@ void netpoll_cleanup(struct netpoll *np)spin_unlock_irqrestore (&npinfo->rx_lock, flags); } - np->dev->npinfo =NULL ;if (atomic_dec_and_test (&npinfo->refcnt)) {skb_queue_purge (&npinfo->arp_tx);skb_queue_purge (&npinfo->txq);
@@ -784,6 +783,7 @@ void netpoll_cleanup(struct netpoll *np)flush_scheduled_work ();kfree (npinfo); + np->dev->npinfo =NULL ; } }
Signature · 3 lines
1.5.2.5 --
PATCH 9/58 Sparc64 bootup assembler bug
In reply to Willy Tarreau[SPARC64]: Fix two year old bug in early bootup asm.
We try to fetch the CIF entry pointer from %o4, but that can get clobbered by the early OBP calls. It is saved in %l7 already, so actually this "mov %o4, %l7" can just be completely removed with no other changes.
--- arch/sparc64/kernel/head.S | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
arch/sparc64/kernel/head.S +0 -1
@@ -458,7 +458,6 @@ tlb_fixup_done: or %g6, %lo(init_thread_union), %g6 ldx [%g6 + TI_TASK], %g4 mov %sp, %l6 - mov %o4, %l7 wr %g0, ASI_P, %asi mov 1, %g1
Signature · 3 lines
1.5.2.5 --
PATCH 11/58 Fix sparc32 udelay() rounding errors.
In reply to Willy Tarreau[SPARC32]: Fix rounding errors in ndelay/udelay implementation.
__ndelay and __udelay have not been delayung >= specified time. The problem with __ndelay has been tacked down to the rounding of the multiplier constant. By changing this, delays > app 18us are correctly calculated.
The problem with __udelay has also been tracked down to rounding issues. Changing the multiplier constant (to match that used in sparc64) corrects for large delays and adding in a rounding constant corrects for trunctaion errors in the claculations.
Many short delays will return without looping. This is not an error as there is the fixed delay of doing all the maths to calculate the loop count.
--- arch/sparc/kernel/entry.S | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-)
arch/sparc/kernel/entry.S +10 -4
@@ -1749,8 +1749,8 @@ fpload: __ndelay: save %sp, -STACKFRAME_SZ, %sp mov %i0, %o0 - call .umul - mov 0x1ad, %o1 ! 2**32 / (1 000 000 000 / HZ) + call .umul ! round multiplier up so large ns ok + mov 0x1ae, %o1 ! 2**32 / (1 000 000 000 / HZ) call .umul mov %i1, %o1 ! udelay_val ba delay_continue
@@ -1760,11 +1760,17 @@ __ndelay: __udelay: save %sp, -STACKFRAME_SZ, %sp mov %i0, %o0 - sethi %hi(0x10c6), %o1 + sethi %hi(0x10c7), %o1 ! round multiplier up so large us ok call .umul - or %o1, %lo(0x10c6), %o1 ! 2**32 / 1 000 000 + or %o1, %lo(0x10c7), %o1 ! 2**32 / 1 000 000 call .umul mov %i1, %o1 ! udelay_val + sethi %hi(0x028f4b62), %l0 ! Add in rounding constant * 2**32, + or %g0, %lo(0x028f4b62), %l0 + addcc %o0, %l0, %o0 ! 2**32 * 0.009 999 + bcs,a 3f + add %o1, 0x01, %o1 +3: call .umul mov HZ, %o0 ! >>32 earlier for wider range
Signature · 3 lines
1.5.2.5 --
PATCH 13/58 KVM: SVM: Reliably detect if SVM was disabled by BIOS
In reply to Willy TarreauThis patch adds an implementation to the svm is_disabled function to detect reliably if the BIOS disabled the SVM feature in the CPU. This fixes the issues with kernel panics when loading the kvm-amd module on machines where SVM is available but disabled.
--- drivers/kvm/svm.c | 6 ++++++ drivers/kvm/svm.h | 3 +++ 2 files changed, 9 insertions(+), 0 deletions(-)
drivers/kvm/svm.c +6 -0
@@ -1655,6 +1655,12 @@ static void svm_inject_page_fault(struct kvm_vcpu *vcpu,static int is_disabled (void ) { +u64 vm_cr; + +rdmsrl (MSR_VM_CR , vm_cr); +if (vm_cr & (1 <<SVM_VM_CR_SVM_DISABLE )) +return 1 ; +return 0 ; }
drivers/kvm/svm.h +3 -0
@@ -172,8 +172,11 @@ struct __attribute__ ((__packed__)) vmcb {#define SVM_CPUID_FUNC 0x8000000a#define MSR_EFER_SVME_MASK (1ULL << 12) +#define MSR_VM_CR 0xc0010114#define MSR_VM_HSAVE_PA 0xc0010117ULL +#define SVM_VM_CR_SVM_DISABLE 4 +#define SVM_SELECTOR_S_SHIFT 4#define SVM_SELECTOR_DPL_SHIFT 5#define SVM_SELECTOR_P_SHIFT 7
Signature · 3 lines
1.5.2.5 --
PATCH 14/58 USB: fix warning caused by autosuspend counter going negative
In reply to Willy TarreauThis patch (as937) fixes a minor bug in the autosuspend usage-counting code. Each hub's usage counter keeps track of the number of unsuspended children. However the current driver increments the counter after registering a new child, by which time the child may already have been suspended and caused the counter to go negative. The obvious solution is to increment the counter before registering the child.
--- drivers/usb/core/hub.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-)
drivers/usb/core/hub.c +4 -0
@@ -1356,6 +1356,10 @@ static int __usb_new_device(void *void_data) }#endif +/* Increment the parent's count of unsuspended children */ +if (udev->parent) +usb_autoresume_device (udev->parent); +/* Register the device. The device driver is responsible * for adding the device files to usbfs and sysfs and for * configuring the device.
@@ -1363,13 +1367,11 @@ static int __usb_new_device(void *void_data) err =device_add (&udev->dev);if (err) { dev_err(&udev->dev, "can't device_add, error %d
", err);
+ if (udev->parent)
+ usb_autosuspend_device(udev->parent);
goto fail;
}
- /* Increment the parent's count of unsuspended children */
- if (udev->parent)
- usb_autoresume_device(udev->parent);
-
exit:
module_put(THIS_MODULE);
return err;
Signature · 3 lines
1.5.2.5 --
PATCH 15/58 aacraid: fix security hole
In reply to Willy TarreauOn the SCSI layer ioctl path there is no implicit permissions check for ioctls (and indeed other drivers implement unprivileged ioctls). aacraid however allows all sorts of very admin only things to be done so should check.
--- drivers/scsi/aacraid/linit.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
drivers/scsi/aacraid/linit.c +4 -0
@@ -539,6 +539,8 @@ static int aac_cfg_open(struct inode *inode, struct file *file)static int aac_cfg_ioctl (struct inode *inode,struct file *file,unsigned int cmd,unsigned long arg) { +if (!capable (CAP_SYS_ADMIN )) +return -EPERM ;return aac_do_ioctl (file->private_data, cmd, (void __user *)arg); }
@@ -592,6 +594,8 @@ static int aac_compat_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)static long aac_compat_cfg_ioctl (struct file *file,unsigned cmd,unsigned long arg) { +if (!capable (CAP_SYS_ADMIN )) +return -EPERM ;return aac_compat_do_ioctl ((struct aac_dev *)file->private_data, cmd, arg); }#endif
Signature · 3 lines
1.5.2.5 --
PATCH 16/58 V4L: Add check for valid control ID to v4l2_ctrl_next
In reply to Willy TarreauIf v4l2_ctrl_next is called without the V4L2_CTRL_FLAG_NEXT_CTRL then it should check whether the passed control ID is valid and return 0 if it isn't. Otherwise a for-loop over the control IDs will never end.
(cherry picked from commit a46c5fbc6912c4e34cb7ded314249b639dc244a6)
--- drivers/media/video/v4l2-common.c | 19 ++++++++++++++----- 1 files changed, 14 insertions(+), 5 deletions(-)
drivers/media/video/v4l2-common.c +14 -5
@@ -1499,16 +1499,25 @@ int v4l2_ctrl_query_menu(struct v4l2_querymenu *qmenu, struct v4l2_queryctrl *qcWhen no more controls are available 0 is returned. */ u32 v4l2_ctrl_next (const u32 *const * ctrl_classes,u32 id) { -u32 ctrl_class; +u32 ctrl_class =V4L2_CTRL_ID2CLASS (id);const u32 *pctrl; -/* if no query is desired, then just return the control ID */ -if ((id &V4L2_CTRL_FLAG_NEXT_CTRL ) ==0 ) -return id;if (ctrl_classes ==NULL )return 0 ; + +/* if no query is desired, then check if the ID is part of ctrl_classes */ +if ((id &V4L2_CTRL_FLAG_NEXT_CTRL ) ==0 ) { +/* find class */ +while (*ctrl_classes &&V4L2_CTRL_ID2CLASS (**ctrl_classes) != ctrl_class) + ctrl_classes++; +if (*ctrl_classes ==NULL ) +return 0 ; + pctrl = *ctrl_classes; +/* find control ID */ +while (*pctrl && *pctrl != id) pctrl++; +return *pctrl ? id :0 ; + } id &=V4L2_CTRL_ID_MASK ; - ctrl_class =V4L2_CTRL_ID2CLASS (id); id++;/* select next control */ /* find first class that matches (or is greater than) the class of the ID */
Signature · 3 lines
1.5.2.5 --
PATCH 17/58 V4L: wm8775/wm8739: Fix memory leak when unloading module
In reply to Willy TarreauState struct was never freed.
(cherry picked from commit 1b2232ab879993fcf5b9391c3febf6ab5d78201e)
--- drivers/media/video/wm8739.c | 2 ++ drivers/media/video/wm8775.c | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-)
drivers/media/video/wm8739.c +2 -0
@@ -317,12 +317,14 @@ static int wm8739_probe(struct i2c_adapter *adapter)static int wm8739_detach (struct i2c_client *client) { +struct wm8739_state *state =i2c_get_clientdata (client);int err; err =i2c_detach_client (client);if (err)return err; +kfree (state);kfree (client);return 0 ; }
drivers/media/video/wm8775.c +2 -0
@@ -218,12 +218,14 @@ static int wm8775_probe(struct i2c_adapter *adapter)static int wm8775_detach (struct i2c_client *client) { +struct wm8775_state *state =i2c_get_clientdata (client);int err; err =i2c_detach_client (client);if (err) {return err; } +kfree (state);kfree (client);return 0 ;
Signature · 3 lines
1.5.2.5 --
PATCH 18/58 splice: fix double page unlock
In reply to Willy TarreauIf add_to_page_cache_lru() fails, the page will not be locked. But splice jumps to an error path that does a page release and unlock, causing a BUG() in unlock_page().
Fix this by adding one more label that just releases the page. This bug was actually triggered on EL5 by gurudas pai <[email protected]> using fio.
--- fs/splice.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
fs/splice.c +3 -2
@@ -614,7 +614,7 @@ find_page: ret =add_to_page_cache_lru (page, mapping, index,GFP_KERNEL );if (unlikely (ret)) - goto out; + goto out_release; }/*
@@ -695,8 +695,9 @@ find_page: goto find_page; } out: -page_cache_release (page);unlock_page (page); +out_release: +page_cache_release (page); out_ret:return ret; }
Signature · 3 lines
1.5.2.5 --
PATCH 19/58 drm/i915: Fix i965 secured batchbuffer usage (CVE-2007-3851)
In reply to Willy TarreauThis 965G and above chipsets moved the batch buffer non-secure bits to another place. This means that previous drm's allowed in-secure batchbuffers to be submitted to the hardware from non-privileged users who are logged into X and and have access to direct rendering.
--- drivers/char/drm/i915_dma.c | 14 +++++++++++--- drivers/char/drm/i915_drv.h | 1 + 2 files changed, 12 insertions(+), 3 deletions(-)
drivers/char/drm/i915_dma.c +11 -3
@@ -172,6 +172,8 @@ static int i915_initialize(drm_device_t * dev,* private backbuffer/depthbuffer usage. */ dev_priv->use_mi_batchbuffer_start =0 ; +if (IS_I965G (dev))/* 965 doesn't support older method */ + dev_priv->use_mi_batchbuffer_start =1 ;/* Allow hardware batchbuffers unless told otherwise. */
@@ -504,8 +506,13 @@ static int i915_dispatch_batchbuffer(drm_device_t * dev,if (dev_priv->use_mi_batchbuffer_start) {BEGIN_LP_RING (2 ); -OUT_RING (MI_BATCH_BUFFER_START | (2 <<6 )); -OUT_RING (batch->start |MI_BATCH_NON_SECURE ); +if (IS_I965G (dev)) { +OUT_RING (MI_BATCH_BUFFER_START | (2 <<6 ) |MI_BATCH_NON_SECURE_I965 ); +OUT_RING (batch->start); + }else { +OUT_RING (MI_BATCH_BUFFER_START | (2 <<6 )); +OUT_RING (batch->start |MI_BATCH_NON_SECURE ); + }ADVANCE_LP_RING (); }else {BEGIN_LP_RING (4 );
@@ -722,7 +729,8 @@ static int i915_setparam(DRM_IOCTL_ARGS)switch (param.param) {case I915_SETPARAM_USE_MI_BATCHBUFFER_START : - dev_priv->use_mi_batchbuffer_start = param.value; +if (!IS_I965G (dev)) + dev_priv->use_mi_batchbuffer_start = param.value;break ;case I915_SETPARAM_TEX_LRU_LOG_GRANULARITY : dev_priv->tex_lru_log_granularity = param.value;
drivers/char/drm/i915_drv.h +1 -0
@@ -280,6 +280,7 @@ extern int i915_wait_ring(drm_device_t * dev, int n, const char *caller);#define MI_BATCH_BUFFER_START (0x31<<23)#define MI_BATCH_BUFFER_END (0xA<<23)#define MI_BATCH_NON_SECURE (1) +#define MI_BATCH_NON_SECURE_I965 (1<<8)#define MI_WAIT_FOR_EVENT ((0x3<<23))#define MI_WAIT_FOR_PLANE_A_FLIP (1<<2)
Signature · 3 lines
1.5.2.5 --
PATCH 20/58 Fix leak on /proc/lockdep_stats
In reply to Willy Tarreau--- kernel/lockdep_proc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
kernel/lockdep_proc.c +1 -1
@@ -323,7 +323,7 @@ static const struct file_operations proc_lockdep_stats_operations = { .open = lockdep_stats_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release, + .release = single_release, };static int __init lockdep_proc_init (void )
Signature · 3 lines
1.5.2.5 --
PATCH 21/58 CPU online file permission
In reply to Willy TarreauIs there a reason why the "online" file in the subdirectories for the CPUs in /sys/devices/system isn't world-readable? I cannot imagine it to be security relevant especially now that a getcpu() syscall can be used to determine what CPUa thread runs on.
The file is useful to correctly implement the sysconf() function to return the number of online CPUs. In the presence of hotplug we currently cannot provide this information. The patch below should to it.
--- drivers/base/cpu.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/base/cpu.c +1 -1
@@ -53,7 +53,7 @@ static ssize_t store_online(struct sys_device *dev, const char *buf, ret = count;return ret; } -static SYSDEV_ATTR(online, 0600, show_online, store_online); +static SYSDEV_ATTR(online, 0644, show_online, store_online);static void __devinit register_cpu_control (struct cpu *cpu) {
Signature · 3 lines
1.5.2.5 --
PATCH 22/58 Fix user struct leakage with locked IPC shem segment
In reply to Willy TarreauWhen user locks an ipc shmem segmant with SHM_LOCK ctl and the segment is already locked the shmem_lock() function returns 0. After this the subsequent code leaks the existing user struct:
== ipc/shm.c: sys_shmctl() ==
...
err = shmem_lock(shp->shm_file, 1, user);
if (!err) {
shp->shm_perm.mode |= SHM_LOCKED;
shp->mlock_user = user;
}
...==
Other results of this are:
1. the new shp->mlock_user is not get-ed and will point to freed memory when the task dies.
2. the RLIMIT_MEMLOCK is screwed on both user structs.
The exploit looks like this:
==
id = shmget(...);
setresuid(uid, 0, 0);
shmctl(id, SHM_LOCK, NULL);
setresuid(uid + 1, 0, 0);
shmctl(id, SHM_LOCK, NULL);==
My solution is to return 0 to the userspace and do not change the segment's user.
--- ipc/shm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
ipc/shm.c +1 -1
@@ -652,7 +652,7 @@ asmlinkage long sys_shmctl (int shmid, int cmd, struct shmid_ds __user *buf)struct user_struct * user = current->user;if (!is_file_hugepages (shp->shm_file)) { err =shmem_lock (shp->shm_file,1 , user); -if (!err) { +if (!err && !(shp->shm_perm.mode &SHM_LOCKED )){ shp->shm_perm.mode |=SHM_LOCKED ; shp->mlock_user = user; }
Signature · 3 lines
1.5.2.5 --
PATCH 23/58 md: handle writes to broken raid10 arrays gracefully
In reply to Willy TarreauWhen writing to a broken array, raid10 currently happily emits empty bio lists. IOW, the master bio will never be completed, sending writers to UNINTERRUPTIBLE_SLEEP forever.
--- drivers/md/raid10.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
drivers/md/raid10.c +7 -0
@@ -917,6 +917,13 @@ static int make_request(request_queue_t *q, struct bio * bio)bio_list_add (&bl, mbio); } +if (unlikely (!atomic_read (&r10_bio->remaining))) { +/* the array is dead */ +md_write_end (mddev); +raid_end_bio_io (r10_bio); +return 0 ; + } +bitmap_startwrite (mddev->bitmap, bio->bi_sector, r10_bio->sectors,0 );spin_lock_irqsave (&conf->device_lock, flags);bio_list_merge (&conf->pending_bio_list, &bl);
Signature · 3 lines
1.5.2.5 --
PATCH 24/58 md: raid10: fix use-after-free of bio
In reply to Willy TarreauIn case of read errors raid10d tries to print a nice error message, unfortunately using data from an already put bio.
--- drivers/md/raid10.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
drivers/md/raid10.c +2 -1
@@ -1565,7 +1565,6 @@ static void raid10d(mddev_t *mddev) bio = r10_bio->devs[r10_bio->read_slot].bio; r10_bio->devs[r10_bio->read_slot].bio = mddev->ro ?IO_BLOCKED :NULL ; -bio_put (bio); mirror =read_balance (conf, r10_bio);if (mirror ==-1 ) { printk(KERN_ALERT "raid10: %s: unrecoverable I/O"
@@ -1573,8 +1572,10 @@ static void raid10d(mddev_t *mddev)bdevname (bio->bi_bdev,b), (unsigned long long)r10_bio->sector);raid_end_bio_io (r10_bio); +bio_put (bio); }else {const int do_sync =bio_sync (r10_bio->master_bio); +bio_put (bio); rdev = conf->mirrors[mirror].rdev;if (printk_ratelimit ()) printk(KERN_ERR "raid10: %s: redirecting sector %llu to"
Signature · 3 lines
1.5.2.5 --
PATCH 25/58 pcmcia: give socket time to power down
In reply to Willy TarreauGive sockets up to 100ms of additional time to power down. otherwise we might generate false warnings with KERN_ERR priority (like in bug #8262).
--- drivers/pcmcia/cs.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
drivers/pcmcia/cs.c +3 -0
@@ -410,6 +410,9 @@ static void socket_shutdown(struct pcmcia_socket *s)#endif s->functions =0 ; +/* give socket some time to power down */ +msleep (100 ); + s->ops->get_status (s, &status); if (status & SS_POWERON) { printk(KERN_ERR "PCMCIA: socket %p: *** DANGER *** unable to remove socket power
", s);
Signature · 3 lines
1.5.2.5 --
PATCH 26/58 "ext4_ext_put_in_cache" uses __u32 to receive physical block number
In reply to Willy TarreauQuoted 4 lines · Yan Zheng
I think I found a bug in
ext4/extents.c, "ext4_ext_put_in_cache" uses "__u32" to receive physical block number. "ext4_ext_put_in_cache" is used in "ext4_ext_get_blocks", it sets ext4 inode's extent cache according most recently tree lookup (higher 16 bits of saved physical
Quoted 9 lines
block number are always zero). when serving a mapping request, "
ext4_ext_get_blocks" first check whether the logical block is in inode's extent cache. if the logical block is in the cache and the cached region isn't a gap, "ext4_ext_get_blocks" gets physical block number by using cached region's physical block number and offset in the cached region. as described above, "ext4_ext_get_blocks" may return wrong result when there are physical block numbers bigger than0xffffffff.
You are right. Thanks for reporting this!
--- fs/ext4/extents.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
fs/ext4/extents.c +1 -1
@@ -1397,7 +1397,7 @@ int ext4_ext_walk_space(struct inode *inode, unsigned long block,static void ext4_ext_put_in_cache (struct inode *inode,__u32 block, -__u32 len,__u32 start,int type) +__u32 len,ext4_fsblk_t start,int type) {struct ext4_ext_cache *cex;BUG_ON (len ==0 );
Signature · 3 lines
1.5.2.5 --
PATCH 27/58 Include serial_reg.h with userspace headers
In reply to Willy TarreauAs reported by Gustavo de Nardin <[email protected]>, while trying to compile xosview (http://xosview.sourceforge.net/) with upstream kernel headers being used you get the following errors:
serialmeter.cc:48:30: error: linux/serial_reg.h: No such file or directory serialmeter.cc: In member function 'virtual void SerialMeter::checkResources()':
serialmeter.cc:71: error: 'UART_LSR' was not declared in this scope serialmeter.cc:71: error: 'UART_MSR' was not declared in this scope ..
--- include/linux/Kbuild | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
include/linux/Kbuild +1 -0
@@ -134,6 +134,7 @@ header-y += radeonfb.h header-y += raw.h header-y += resource.h header-y += rose.h +header-y += serial_reg.h header-y += smbno.h header-y += snmp.h header-y += sockios.h
Signature · 3 lines
1.5.2.5 --
Re: [2.6.20.17 review 27/58] Include serial_reg.h with userspace headers
Quoted 9 lines · Willy Tarreau
As reported by Gustavo de Nardin <[email protected]>, while trying to compile xosview (http://xosview.sourceforge.net/) with upstream kernel headers being used you get the following errors:
serialmeter.cc:48:30: error:linux/serial_reg.h: No such file or directory serialmeter.cc: In member function 'virtual voidSerialMeter::checkResources()':
serialmeter.cc:71: error: 'UART_LSR' was not declared in this scope serialmeter.cc:71: error: 'UART_MSR' was not declared in this scope ..
It's probably a good thing to repeat what I said privately about this, which is:
| It should be noted that reading the MSR or LSR of an active 8250 UART | has side effects. In the case of MSR, it clears the bits which indicate | that the modem status signals have changed, and clears the associated | interrupt. This can result in loss of hardware flow control on the port. | | For LSR, a read clears the error status reported in that register and | clears the interrupt associated with the error status, resulting in | errors being missed. | | So, reading the LSR and MSR of an active port is Bad News(tm) and is | something that userspace should absolutely avoid. Instead, userspace | should open the port in non-blocking mode and use the TIOCGICOUNT | ioctl to retrieve the various activity counters and TIOCMGET to obtain | the current modem status line state. | | I would encourage xosview folk to switch to use these ioctls rather than | reading the registers direct for the following reasons: | | 1. It's supported by a wide variety of serial port implementations. | 2. Avoids the mess associated with ioperm support noted in serialmeter.cc | revision 1.11 | 3. Avoids including kernel private kernel headers. | 4. Avoids the buggy "autodetection" of serial IO base (which ignores the | IO type of the port, which may be MMIO.) | 5. Avoids side effects associated with reading the ports registers. | | For a tool which presumably is to assist diagnosing serial problems, it | would seem to have the capability of causing further additional problems.
I leave it up to others to decide that keeping backwards compatibility with userspace which is quite obviously broken is more important than providing userspace with the persuasion to fix their broken code.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Re: [2.6.20.17 review 27/58] Include serial_reg.h with userspace headers
Hi Russell,
Quoted 18 lines · Russell King
Quoted 9 lines · Willy Tarreau
As reported by Gustavo de Nardin <[email protected]>, while trying to compile xosview (http://xosview.sourceforge.net/) with upstream kernel headers being used you get the following errors:
serialmeter.cc:48:30: error:linux/serial_reg.h: No such file or directory serialmeter.cc: In member function 'virtual voidSerialMeter::checkResources()':
serialmeter.cc:71: error: 'UART_LSR' was not declared in this scope serialmeter.cc:71: error: 'UART_MSR' was not declared in this scope ..It's probably a good thing to repeat what I said privately about this, which is:
| It should be noted that reading the MSR or LSR of an active 8250 UART | has side effects. In the case of MSR, it clears the bits which indicate | that the modem status signals have changed, and clears the associated | interrupt. This can result in loss of hardware flow control on the port.
(...)
Quoted 6 lines
| For a tool which presumably is to assist diagnosing serial problems, it | would seem to have the capability of causing further additional problems.
I leave it up to others to decide that keeping backwards compatibility with userspace which is quite obviously broken is more important than providing userspace with the persuasion to fix their broken code.
While I agree with you that side effects may be undesirable, I still think it's important to ensure backwards compatibility in -stable branch, for the following reasons :
- people who use -stable want to ensure that they can upgrade in order to fix security issues or other bugs without risking (much) regression
- you do not prevent buggy programs from doing wrong things by removing headers. What you will end up with is xosview using the quite common #ifndef UART_LSR / #define UART_LSR / #endif. In fact, there *may* be some legitimate uses of those defines, eventhough this program abuses its capabilities.
Eventhough it's not a good practise to rely on kernel headers for userspace, at least we should limit build regressions on the user side, as it does not help the end user understand that the program he builds is wrong.
Thanks,
Willy
PATCH 28/58 dm io: fix panic on large request
In reply to Willy TarreauFlush workqueue before releasing bioset and mopools in dm-crypt. There can be finished but not yet released request.
Call chain causing oops:
run workqueue
dec_pending
bio_endio(...);
<remove device request - remove mempool>
mempool_free(io, cc->io_pool);This usually happens when cryptsetup create temporary luks mapping in the beggining of crypt device activation.
When dm-core calls destructor crypt_dtr, no new request are possible.
--- drivers/md/dm-crypt.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
drivers/md/dm-crypt.c +2 -0
@@ -917,6 +917,8 @@ static void crypt_dtr(struct dm_target *ti) {struct crypt_config *cc = (struct crypt_config *) ti->private; +flush_workqueue (_kcryptd_workqueue); +bioset_free (cc->bs);mempool_destroy (cc->page_pool);mempool_destroy (cc->io_pool);
Signature · 3 lines
1.5.2.5 --
PATCH 29/58 softmac: Fix ESSID problem
In reply to Willy TarreauVictor Porton reported that the SoftMAC layer had random problem when setting the ESSID :
http://bugzilla.kernel.org/show_bug.cgi?id=8686 After investigation, it turned out to be worse, the SoftMAC layer is left in an inconsistent state. The fix is pretty trivial.
--- net/ieee80211/softmac/ieee80211softmac_assoc.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
net/ieee80211/softmac/ieee80211softmac_assoc.c +0 -0
@@ -271,8 +271,11 @@ ieee80211softmac_assoc_work(struct work_struct *work)*/ dprintk(KERN_INFO PFX "Associate: Scanning for networks first.
");
ieee80211softmac_notify(mac->dev, IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, ieee80211softmac_assoc_notify_scan, NULL);
- if (ieee80211softmac_start_scan(mac))
+ if (ieee80211softmac_start_scan(mac)) {
dprintk(KERN_INFO PFX "Associate: failed to initiate scan. Is device up?
");
+ mac->associnfo.associating = 0;
+ mac->associnfo.associated = 0;
+ }
goto out;
} else {
mac->associnfo.associating = 0;
Signature · 3 lines
1.5.2.5 --
PATCH 30/58 nfsd: fix possible read-ahead cache and export table corruption
In reply to Willy TarreauThe value of nperbucket calculated here is too small--we should be rounding up instead of down--with the result that the index j in the following loop can overflow the raparm_hash array. At least in my case, the next thing in memory turns out to be export_table, so the symptoms I see are crashes caused by the appearance of four zeroed-out export entries in the first bucket of the hash table of exports (which were actually entries in the readahead cache, a pointer to which had been written to the export table in this initialization code).
It looks like the bug was probably introduced with commit fce1456a19f5c08b688c29f00ef90fdfa074c79b ("knfsd: make the readahead params cache SMP-friendly").
--- fs/nfsd/vfs.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
fs/nfsd/vfs.c +1 -1
@@ -1887,7 +1887,7 @@ nfsd_racache_init(int cache_size) raparm_hash[i].pb_head =NULL ;spin_lock_init (&raparm_hash[i].pb_lock); } - nperbucket = cache_size >>RAPARM_HASH_BITS ; + nperbucket =DIV_ROUND_UP (cache_size,RAPARM_HASH_SIZE );for (i =0 ; i < cache_size -1 ; i++) {if (i % nperbucket ==0 ) raparm_hash[j++].pb_head = raparml + i;
Signature · 3 lines
1.5.2.5 --
PATCH 31/58 readahead: MIN_RA_PAGES/MAX_RA_PAGES macros
In reply to Willy TarreauDefine two convenient macros for read-ahead:
- MAX_RA_PAGES: rounded down counterpart of VM_MAX_READAHEAD
- MIN_RA_PAGES: rounded _up_ counterpart of VM_MIN_READAHEAD
Note that the rounded up MIN_RA_PAGES will work flawlessly with _large_ page sizes like 64k.
--- mm/readahead.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-)
mm/readahead.c +10 -2
@@ -21,8 +21,16 @@ void default_unplug_io_fn(struct backing_dev_info *bdi, struct page *page) }EXPORT_SYMBOL (default_unplug_io_fn); +/* +* Convienent macros for min/max read-ahead pages. +* Note that MAX_RA_PAGES is rounded down, while MIN_RA_PAGES is rounded up. +* The latter is necessary for systems with large page size(i.e. 64k). +*/ +#define MAX_RA_PAGES (VM_MAX_READAHEAD*1024 / PAGE_CACHE_SIZE) +#define MIN_RA_PAGES DIV_ROUND_UP(VM_MIN_READAHEAD*1024, PAGE_CACHE_SIZE) +struct backing_dev_info default_backing_dev_info = { - .ra_pages = (VM_MAX_READAHEAD *1024 ) /PAGE_CACHE_SIZE , + .ra_pages =MAX_RA_PAGES , .state =0 , .capabilities =BDI_CAP_MAP_COPY , .unplug_io_fn = default_unplug_io_fn,
@@ -51,7 +59,7 @@ static inline unsigned long get_max_readahead(struct file_ra_state *ra)static inline unsigned long get_min_readahead (struct file_ra_state *ra) { -return (VM_MIN_READAHEAD *1024 ) /PAGE_CACHE_SIZE ; +return MIN_RA_PAGES ; }static inline void reset_ahead_window (struct file_ra_state *ra)
Signature · 3 lines
1.5.2.5 --
PATCH 32/58 fs: 9p/conv.c error path fix
In reply to Willy TarreauWhen buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err)) and it will not be happy about it.
--- fs/9p/conv.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
fs/9p/conv.c +1 -0
@@ -742,6 +742,7 @@ struct v9fs_fcall *v9fs_create_twrite(u32 fid, u64 offset, u32 count,if (err) {kfree (fc); fc =ERR_PTR (err); + goto error; }if (buf_check_overflow (bufp)) {
Signature · 3 lines
1.5.2.5 --
Re: [2.6.20.17 review 32/58] fs: 9p/conv.c error path fix
Quoted 7 lines · Willy Tarreau
When
buf_check_overflow()returns != 0 we will hit kfree(ERR_PTR(err)) and it will not be happy about it.Signed-off-by Mariusz Kozlowski <[email protected]>Cc Andrew Morton <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Signed-off-by Willy Tarreau <[email protected]>
This seems to be in the current code as well, I'll forward-port the patch...
-eric
Re: [2.6.20.17 review 32/58] fs: 9p/conv.c error path fix
Quoted 11 lines · Eric Van Hensbergen
Quoted 7 lines · Willy Tarreau
When
buf_check_overflow()returns != 0 we will hit kfree(ERR_PTR(err)) and it will not be happy about it.Signed-off-by Mariusz Kozlowski <[email protected]>Cc Andrew Morton <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Signed-off-by Willy Tarreau <[email protected]>This seems to be in the current code as well, I'll forward-port the patch...
Thanks Eric,
Willy
Re: [stable] [2.6.20.17 review 32/58] fs: 9p/conv.c error path fix
In reply to Eric Van HensbergenQuoted 11 lines · Eric Van Hensbergen
Quoted 7 lines · Willy Tarreau
When
buf_check_overflow()returns != 0 we will hit kfree(ERR_PTR(err)) and it will not be happy about it.Signed-off-by Mariusz Kozlowski <[email protected]>Cc Andrew Morton <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Signed-off-by Willy Tarreau <[email protected]>This seems to be in the current code as well, I'll forward-port the patch...
Huh? It's not already in mainline? Then how did it ever get into the stable queue?
Ugh.
greg k-h
Re: [stable] [2.6.20.17 review 32/58] fs: 9p/conv.c error path fix
Hi Greg,
Quoted 9 lines · Greg KH
Quoted 8 lines · Eric Van Hensbergen
Quoted 7 lines · Willy Tarreau
When
buf_check_overflow()returns != 0 we will hit kfree(ERR_PTR(err)) and it will not be happy about it.Signed-off-by Mariusz Kozlowski <[email protected]>Cc Andrew Morton <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Signed-off-by Willy Tarreau <[email protected]>
Quoted 8 lines
Quoted 3 lines
This seems to be in the current code as well, I'll forward-port the patch...
Huh? It's not already in mainline? Then how did it ever get into the stable queue?
Ugh.
Maybe someone sent it to stable@ and lkml at the same time and it got lost on the second (noisy) path ? Judging from the patch, it got merged about one month ago :
willy@pcw:2.6$ git log v2.6.20..2.6.22.x -- fs/9p/conv.c|cat commit b3b590287ca3c36e0a3fa28d626f126dd5226fc4 Author: Mariusz Kozlowski <[email protected]> Date: Thu Jul 19 17:27:22 2007 -0700
fs: 9p/conv.c error path fix
When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err)) and it will not be happy about it.
willy@pcw:2.6$ git describe b3b590287ca3c36e0a3fa28d626f126dd5226fc4 v2.6.22.1-53-gb3b5902
But yes, I agree that it's very annoying when -stable contains patches that are not in mainline. Fortunately, we have careful reviewers to catch this when it happens !
Regards,
Willy
PATCH 33/58 forcedeth bug fix: cicada phy
In reply to Willy TarreauThis patch contains errata fixes for the cicada phy. It only renamed the defines to be phy specific.
--- drivers/net/forcedeth.c | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-)
drivers/net/forcedeth.c +8 -8
@@ -560,12 +560,12 @@ union ring_type {#define PHYID2_MODEL_MASK 0x03f0#define PHY_MODEL_MARVELL_E3016 0x220#define PHY_MARVELL_E3016_INITMASK 0x0300 -#define PHY_INIT1 0x0f000 -#define PHY_INIT2 0x0e00 -#define PHY_INIT3 0x01000 -#define PHY_INIT4 0x0200 -#define PHY_INIT5 0x0004 -#define PHY_INIT6 0x02000 +#define PHY_CICADA_INIT1 0x0f000 +#define PHY_CICADA_INIT2 0x0e00 +#define PHY_CICADA_INIT3 0x01000 +#define PHY_CICADA_INIT4 0x0200 +#define PHY_CICADA_INIT5 0x0004 +#define PHY_CICADA_INIT6 0x02000#define PHY_GIGABIT 0x0100#define PHY_TIMEOUT 0x1
@@ -1133,14 +1133,14 @@ static int phy_init(struct net_device *dev)/* phy vendor specific configuration */ if ((np->phy_oui == PHY_OUI_CICADA) && (phyinterface & PHY_RGMII) ) { phy_reserved = mii_rw(dev, np->phyaddr, MII_RESV1, MII_READ); - phy_reserved &= ~(PHY_INIT1 | PHY_INIT2); - phy_reserved |= (PHY_INIT3 | PHY_INIT4); + phy_reserved &= ~(PHY_CICADA_INIT1 | PHY_CICADA_INIT2); + phy_reserved |= (PHY_CICADA_INIT3 | PHY_CICADA_INIT4); if (mii_rw(dev, np->phyaddr, MII_RESV1, phy_reserved)) { printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
return PHY_ERROR;
}
phy_reserved = mii_rw(dev, np->phyaddr, MII_NCONFIG, MII_READ);
- phy_reserved |= PHY_INIT5;
+ phy_reserved |= PHY_CICADA_INIT5;
if (mii_rw(dev, np->phyaddr, MII_NCONFIG, phy_reserved)) {
printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
return PHY_ERROR;
@@ -1148,7 +1148,7 @@ static int phy_init(struct net_device *dev)
}
if (np->phy_oui == PHY_OUI_CICADA) {
phy_reserved = mii_rw(dev, np->phyaddr, MII_SREVISION, MII_READ);
- phy_reserved |= PHY_INIT6;
+ phy_reserved |= PHY_CICADA_INIT6;
if (mii_rw(dev, np->phyaddr, MII_SREVISION, phy_reserved)) {
printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
return PHY_ERROR;
Signature · 3 lines
1.5.2.5 --
PATCH 34/58 forcedeth bug fix: vitesse phy
In reply to Willy TarreauThis patch contains errata fixes for the vitesse phy. It only renamed the defines to be phy specific.
--- drivers/net/forcedeth.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 88 insertions(+), 0 deletions(-)
drivers/net/forcedeth.c +21 -0
@@ -553,6 +553,7 @@ union ring_type {/* PHY defines */ #define PHY_OUI_MARVELL 0x5043#define PHY_OUI_CICADA 0x03f1 +#define PHY_OUI_VITESSE 0x01c1#define PHYID1_OUI_MASK 0x03ff#define PHYID1_OUI_SHFT 6#define PHYID2_OUI_MASK 0xfc00
@@ -566,6 +567,23 @@ union ring_type {#define PHY_CICADA_INIT4 0x0200#define PHY_CICADA_INIT5 0x0004#define PHY_CICADA_INIT6 0x02000 +#define PHY_VITESSE_INIT_REG1 0x1f +#define PHY_VITESSE_INIT_REG2 0x10 +#define PHY_VITESSE_INIT_REG3 0x11 +#define PHY_VITESSE_INIT_REG4 0x12 +#define PHY_VITESSE_INIT_MSK1 0xc +#define PHY_VITESSE_INIT_MSK2 0x0180 +#define PHY_VITESSE_INIT1 0x52b5 +#define PHY_VITESSE_INIT2 0xaf8a +#define PHY_VITESSE_INIT3 0x8 +#define PHY_VITESSE_INIT4 0x8f8a +#define PHY_VITESSE_INIT5 0xaf86 +#define PHY_VITESSE_INIT6 0x8f86 +#define PHY_VITESSE_INIT7 0xaf82 +#define PHY_VITESSE_INIT8 0x0100 +#define PHY_VITESSE_INIT9 0x8f82 +#define PHY_VITESSE_INIT10 0x0 +#define PHY_GIGABIT 0x0100#define PHY_TIMEOUT 0x1
@@ -1154,6 +1172,76 @@ static int phy_init(struct net_device *dev)return PHY_ERROR ; } } + if (np->phy_oui == PHY_OUI_VITESSE) { + if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG1, PHY_VITESSE_INIT1)) { + printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT2)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, MII_READ);
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, phy_reserved)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, MII_READ);
+ phy_reserved &= ~PHY_VITESSE_INIT_MSK1;
+ phy_reserved |= PHY_VITESSE_INIT3;
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, phy_reserved)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT4)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT5)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, MII_READ);
+ phy_reserved &= ~PHY_VITESSE_INIT_MSK1;
+ phy_reserved |= PHY_VITESSE_INIT3;
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, phy_reserved)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, MII_READ);
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, phy_reserved)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT6)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT7)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, MII_READ);
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, phy_reserved)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, MII_READ);
+ phy_reserved &= ~PHY_VITESSE_INIT_MSK2;
+ phy_reserved |= PHY_VITESSE_INIT8;
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, phy_reserved)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT9)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG1, PHY_VITESSE_INIT10)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ }
/* some phys clear out pause advertisment on reset, set it back */ mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
Signature · 3 lines
1.5.2.5 --
PATCH 35/58 forcedeth bug fix: realtek phy
In reply to Willy TarreauThis patch contains errata fixes for the realtek phy. It only renamed the defines to be phy specific.
--- drivers/net/forcedeth.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 54 insertions(+), 0 deletions(-)
drivers/net/forcedeth.c +11 -0
@@ -554,6 +554,7 @@ union ring_type {#define PHY_OUI_MARVELL 0x5043#define PHY_OUI_CICADA 0x03f1#define PHY_OUI_VITESSE 0x01c1 +#define PHY_OUI_REALTEK 0x01c1#define PHYID1_OUI_MASK 0x03ff#define PHYID1_OUI_SHFT 6#define PHYID2_OUI_MASK 0xfc00
@@ -583,6 +584,13 @@ union ring_type {#define PHY_VITESSE_INIT8 0x0100#define PHY_VITESSE_INIT9 0x8f82#define PHY_VITESSE_INIT10 0x0 +#define PHY_REALTEK_INIT_REG1 0x1f +#define PHY_REALTEK_INIT_REG2 0x19 +#define PHY_REALTEK_INIT_REG3 0x13 +#define PHY_REALTEK_INIT1 0x0000 +#define PHY_REALTEK_INIT2 0x8e00 +#define PHY_REALTEK_INIT3 0x0001 +#define PHY_REALTEK_INIT4 0xad17#define PHY_GIGABIT 0x0100
@@ -1106,6 +1114,28 @@ static int phy_init(struct net_device *dev)return PHY_ERROR ; } } + if (np->phy_oui == PHY_OUI_REALTEK) { + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1)) { + printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG2, PHY_REALTEK_INIT2)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT3)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG3, PHY_REALTEK_INIT4)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ }
/* set advertise register */
reg = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ);
@@ -1242,6 +1272,30 @@ static int phy_init(struct net_device *dev)
return PHY_ERROR;
}
}
+ if (np->phy_oui == PHY_OUI_REALTEK) {
+ /* reset could have cleared these out, set them back */
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG2, PHY_REALTEK_INIT2)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT3)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG3, PHY_REALTEK_INIT4)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1)) {
+ printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+ return PHY_ERROR;
+ }
+ }
+
/* some phys clear out pause advertisment on reset, set it back */ mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
Signature · 3 lines
1.5.2.5 --
Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy
Quoted 15 lines · Willy Tarreau
This patch contains errata fixes for the realtek phy. It only renamed the defines to be phy specific.
Signed-off-by Ayaz Abdulla <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Signed-off-by Willy Tarreau <[email protected]>--- drivers/net/forcedeth.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 54 insertions(+), 0 deletions(-)drivers/net/forcedeth.c +0
-0
drivers/net/forcedeth.c union ring_type { · line 560
Quoted 7 lines
drivers/net/forcedeth.c +1
-0@@ -554,6 +554,7 @@ union ring_type {#define PHY_OUI_MARVELL 0x5043#define PHY_OUI_CICADA 0x03f1#define PHY_OUI_VITESSE 0x01c1 +#define PHY_OUI_REALTEK 0x01c1#define PHYID1_OUI_MASK 0x03ff#define PHYID1_OUI_SHFT 6#define PHYID2_OUI_MASK 0xfc00
Realtek is 0x0732
This is still wrong upstream -- what happened to the patch to fix it?
Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy
Quoted 26 lines · Chuck Ebbert
Quoted 15 lines · Willy Tarreau
This patch contains errata fixes for the realtek phy. It only renamed the defines to be phy specific.
Signed-off-by Ayaz Abdulla <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Signed-off-by Willy Tarreau <[email protected]>--- drivers/net/forcedeth.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 54 insertions(+), 0 deletions(-)drivers/net/forcedeth.c +0
-0drivers/net/forcedeth.c union ring_type { · line 560
Quoted 7 lines
drivers/net/forcedeth.c +1
-0@@ -554,6 +554,7 @@ union ring_type {#define PHY_OUI_MARVELL 0x5043#define PHY_OUI_CICADA 0x03f1#define PHY_OUI_VITESSE 0x01c1 +#define PHY_OUI_REALTEK 0x01c1#define PHYID1_OUI_MASK 0x03ff#define PHYID1_OUI_SHFT 6#define PHYID2_OUI_MASK 0xfc00Realtek is
0x0732
Quoted 1 line
This is still wrong upstream -- what happened to the patch to fix it?
Good catch, thanks Chuck! I've already seen the fix somewhere, I believe it was on netdev, though I'm not sure. I'm fixing the patch in place right now. I can add your signoff if you want.
Cheers,
Willy
Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy
In reply to Willy TarreauHi,
even if Greg is waiting for some special invitation
(http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on top:
http://lkml.org/lkml/2007/8/10/296
Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
bye,
Prakash
On the day of Wednesday 22 August 2007 Willy Tarreau hast written:
Quoted 109 lines
This patch contains errata fixes for the realtek phy. It only renamed the defines to be phy specific.
Signed-off-by Ayaz Abdulla <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Signed-off-by Willy Tarreau <[email protected]>--- drivers/net/forcedeth.c | 54+++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 54 insertions(+), 0 deletions(-)
drivers/net/forcedeth.c +10
-0@@ -554,6 +554,7 @@ union ring_type {#define PHY_OUI_MARVELL 0x5043#define PHY_OUI_CICADA 0x03f1#define PHY_OUI_VITESSE 0x01c1 +#define PHY_OUI_REALTEK 0x01c1#define PHYID1_OUI_MASK 0x03ff#define PHYID1_OUI_SHFT 6#define PHYID2_OUI_MASK 0xfc00@@ -583,6 +584,13 @@ union ring_type {#define PHY_VITESSE_INIT8 0x0100#define PHY_VITESSE_INIT9 0x8f82#define PHY_VITESSE_INIT10 0x0 +#define PHY_REALTEK_INIT_REG1 0x1f +#define PHY_REALTEK_INIT_REG2 0x19 +#define PHY_REALTEK_INIT_REG3 0x13 +#define PHY_REALTEK_INIT1 0x0000 +#define PHY_REALTEK_INIT2 0x8e00 +#define PHY_REALTEK_INIT3 0x0001 +#define PHY_REALTEK_INIT4 0xad17#define PHY_GIGABIT 0x0100@@ -1106,6 +1114,28 @@ static int phy_init(struct net_device *dev)return PHY_ERROR ; } } +if (np->phy_oui ==PHY_OUI_REALTEK ) { +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG1 ,PHY_REALTEK_INIT1 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +3
-0+return PHY_ERROR ; + } +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG2 ,PHY_REALTEK_INIT2 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +3
-0+return PHY_ERROR ; + } +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG1 ,PHY_REALTEK_INIT3 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +3
-0+return PHY_ERROR ; + } +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG3 ,PHY_REALTEK_INIT4 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +3
-0+return PHY_ERROR ; + } +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG1 ,PHY_REALTEK_INIT1 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +6
-0+return PHY_ERROR ; + } + }/* set advertise register */ reg =mii_rw (dev, np->phyaddr,MII_ADVERTISE ,MII_READ );@@ -1242,6 +1272,30 @@ static int phy_init(struct net_device *dev)return PHY_ERROR ; } } +if (np->phy_oui ==PHY_OUI_REALTEK ) { +/* reset could have cleared these out, set them back */ +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG1 ,PHY_REALTEK_INIT1 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +3
-0+return PHY_ERROR ; + } +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG2 ,PHY_REALTEK_INIT2 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +3
-0+return PHY_ERROR ; + } +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG1 ,PHY_REALTEK_INIT3 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +3
-0+return PHY_ERROR ; + } +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG3 ,PHY_REALTEK_INIT4 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +3
-0+return PHY_ERROR ; + } +if (mii_rw (dev, np->phyaddr,PHY_REALTEK_INIT_REG1 ,PHY_REALTEK_INIT1 )){ + printk(KERN_INFO "%s: phy init failed.
",pci_name(np->pci_dev));drivers/net/forcedeth.c +4
-1+return PHY_ERROR ; + } + } +/* some phys clear out pause advertisment on reset, set it back */ mii_rw (dev, np->phyaddr,MII_ADVERTISE , reg); --1.5.2.5
Signature · 3 lines
(°= =°) //\ Prakash Punnoor /\\ V_/ \_V
Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy
Quoted 7 lines · Prakash Punnoor
Hi,
even if Greg is waiting for some special invitation
(http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on top:
That's what I prepare first, but then noticed it's not in mainline.
Quoted 1 line
Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
He should, as the fix is not in mainline either :-(
I don't think Greg asks for specific clarification, just a plain patch with a short commit log on its own which does not include remains of older mails.
I'm holding up the patch until I get confirmation that it is *at least* queued for mainline, otherwise it will definitely be missing from mainline.
Thanks Prakash for the pointers above.
Willy
Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy
Quoted 9 lines · Willy Tarreau
Quoted 7 lines · Prakash Punnoor
Hi,
even if Greg is waiting for some special invitation
(http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on top:
Quoted 8 lines
That's what I prepare first, but then noticed it's not in mainline.
Quoted 1 line
Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
He should, as the fix is not in mainline either :-(
I don't think Greg asks for specific clarification, just a plain patch with a short commit log on its own which does not include remains of older mails.
Exactly, that is what I am waiting for.
And also I need the change to go into mainline first, as we can not diverge with the -stable releases.
thanks,
greg k-h
Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy
On the day of Thursday 23 August 2007 Greg KH hast written:
Quoted 19 lines · Willy Tarreau
Quoted 9 lines · Prakash Punnoor
Quoted 7 lines
Hi,
even if Greg is waiting for some special invitation
(http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on top:Quoted 8 lines
That's what I prepare first, but then noticed it's not in mainline.
Quoted 1 line
Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
He should, as the fix is not in mainline either :-(
I don't think Greg asks for specific clarification, just a plain patch with a short commit log on its own which does not include remains of older mails.
Quoted 4 lines
Exactly, that is what I am waiting for.
And also I need the change to go into mainline first, as we can not diverge with the -stable releases.
Can we get that into mainline then? I haven't seen forcedeth in MAINTAINERS, so I added netdev to the cc list.
bye,
Signature · 3 lines
(°= =°) //\ Prakash Punnoor /\\ V_/ \_V
Re: [stable] [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy
Quoted 20 lines · Prakash Punnoor
On the day of Thursday 23 August 2007 Greg KH hast written:
Quoted 19 lines · Willy Tarreau
Quoted 17 lines · Prakash Punnoor
Quoted 7 lines
Hi,
even if Greg is waiting for some special invitation
(http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on top:That's what I prepare first, but then noticed it's not in mainline.
Quoted 1 line
Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
He should, as the fix is not in mainline either :-(
I don't think Greg asks for specific clarification, just a plain patch with a short commit log on its own which does not include remains of older mails.
Quoted 7 lines
Quoted 4 lines
Exactly, that is what I am waiting for.
And also I need the change to go into mainline first, as we can not diverge with the -stable releases.
Can we get that into mainline then? I haven't seen forcedeth in
MAINTAINERS, so I added netdev to the cc list.
It might help if someone sends a real patch that can be applied :)
thanks,
greg k-h
PATCH 1/1 fix realtek phy id in forcedeth
Hi Greg,
Quoted 1 line · Greg KH
It might help if someone sends a real patch that can be applied :)
This is getting really silly now :-) We're all wasting more time wondering who will send the patch than posting it. I've lost, I got fed up first, so here it is. Please apply to mainline then stable.
Thanks,
Willy
--
Quoted 1 line
From
a0e2922b99eedd9863232368ea2afe072c52783eMon Sep 17 00:00:00 2001
From: Willy Tarreau <[email protected]>
Date: Thu, 23 Aug 2007 21:35:41 +0200
Subject: [PATCH] fix realtek phy id in forcedeth
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.
--- drivers/net/forcedeth.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/net/forcedeth.c +1 -1
@@ -552,7 +552,7 @@ union ring_type {#define PHY_OUI_MARVELL 0x5043#define PHY_OUI_CICADA 0x03f1#define PHY_OUI_VITESSE 0x01c1 -#define PHY_OUI_REALTEK 0x01c1 +#define PHY_OUI_REALTEK 0x0732#define PHYID1_OUI_MASK 0x03ff#define PHYID1_OUI_SHFT 6#define PHYID2_OUI_MASK 0xfc00
Signature · 1 line
1.5.2.5
Jeff Garzik
AppliedRe: [PATCH] fix realtek phy id in forcedeth
Quoted 23 lines · Willy Tarreau
Hi Greg,
Quoted 1 line · Greg KH
It might help if someone sends a real patch that can be applied :)
This is getting really silly now :-) We're all wasting more time wondering who will send the patch than posting it. I've lost, I got fed up first, so here it is. Please apply to mainline then stable.
Thanks,
Willy--
Quoted 1 line
From
a0e2922b99eedd9863232368ea2afe072c52783eMon Sep 17 00:00:00 2001From: Willy Tarreau <[email protected]>
Date: Thu, 23 Aug 2007 21:35:41 +0200
Subject: [PATCH] fix realtek phy id in forcedethAs noticed by Chuck Ebbert, commit
c5e3ae8823693b260ce1f217adca8add1bc0b3deintroduced a copy-paste typo, as realtek phy is0x732and not0x1c1. Obvious fix below suggested by Ayaz Abdulla.
Quoted 6 lines
Signed-off-by Willy Tarreau <[email protected]>Cc Ayaz Abdulla <[email protected]>Cc Chuck Ebbert <[email protected]>--- drivers/net/forcedeth.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
applied
PATCH 36/58 acpi-cpufreq: Proper ReadModifyWrite of PERF_CTL MSR
In reply to Willy Tarreau[CPUFREQ] acpi-cpufreq: Proper ReadModifyWrite of PERF_CTL MSR
During recent acpi-cpufreq changes, writing to PERF_CTL msr changed from RMW of entire 64 bit to RMW of low 32 bit and clearing of upper 32 bit. Fix it back to do a proper RMW of the MSR.
--- arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-)
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c +5 -8
@@ -167,11 +167,13 @@ static void do_drv_read(struct drv_cmd *cmd)static void do_drv_write (struct drv_cmd *cmd) { -u32 h =0 ; +u32 lo, hi;switch (cmd->type) {case SYSTEM_INTEL_MSR_CAPABLE : -wrmsr (cmd->addr.msr.reg, cmd->val, h); +rdmsr (cmd->addr.msr.reg, lo, hi); + lo = (lo & ~INTEL_MSR_RANGE ) | (cmd->val &INTEL_MSR_RANGE ); +wrmsr (cmd->addr.msr.reg, lo, hi);break ;case SYSTEM_IO_CAPABLE : acpi_os_write_port((acpi_io_address)cmd->addr.io.port,
@@ -372,7 +374,6 @@ static int acpi_cpufreq_target(struct cpufreq_policy *policy,struct cpufreq_freqs freqs;cpumask_t online_policy_cpus;struct drv_cmd cmd; -unsigned int msr;unsigned int next_state =0 ;/* Index into freq_table */ unsigned int next_perf_state =0 ;/* Index into perf table */ unsigned int i;
@@ -417,11 +418,7 @@ static int acpi_cpufreq_target(struct cpufreq_policy *policy,case SYSTEM_INTEL_MSR_CAPABLE : cmd.type =SYSTEM_INTEL_MSR_CAPABLE ; cmd.addr.msr.reg =MSR_IA32_PERF_CTL ; - msr = - (u32 ) perf->states[next_perf_state]. - control &INTEL_MSR_RANGE ; - cmd.val =get_cur_val (online_policy_cpus); - cmd.val = (cmd.val & ~INTEL_MSR_RANGE ) | msr; + cmd.val = (u32 ) perf->states[next_perf_state].control;break ;case SYSTEM_IO_CAPABLE : cmd.type =SYSTEM_IO_CAPABLE ;
Signature · 3 lines
1.5.2.5 --
PATCH 38/58 jbd2 commit: fix transaction dropping
In reply to Willy TarreauWe have to check that also the second checkpoint list is non-empty before dropping the transaction.
--- fs/jbd/commit.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
fs/jbd/commit.c +2 -1
@@ -888,7 +888,8 @@ restart_loop: journal->j_committing_transaction =NULL ;spin_unlock (&journal->j_state_lock); -if (commit_transaction->t_checkpoint_list ==NULL ) { +if (commit_transaction->t_checkpoint_list ==NULL && + commit_transaction->t_checkpoint_io_list ==NULL ) {__journal_drop_transaction (journal, commit_transaction); }else {if (journal->j_checkpoint_transactions ==NULL ) {
Signature · 3 lines
1.5.2.5 --
PATCH 39/58 hugetlb: fix race in alloc_fresh_huge_page()
In reply to Willy TarreauThat static `nid' index needs locking. Without it we can end up calling alloc_pages_node() with an illegal node ID and the kernel crashes.
--- mm/hugetlb.c | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-)
mm/hugetlb.c +11 -4
@@ -101,13 +101,20 @@ static void free_huge_page(struct page *page)static int alloc_fresh_huge_page (void ) { -static int nid =0 ; +static int prev_nid;struct page *page; - page =alloc_pages_node (nid,GFP_HIGHUSER |__GFP_COMP|__GFP_NOWARN, -HUGETLB_PAGE_ORDER ); - nid =next_node (nid, node_online_map); +static DEFINE_SPINLOCK (nid_lock); +int nid; + +spin_lock (&nid_lock); + nid =next_node (prev_nid, node_online_map);if (nid ==MAX_NUMNODES ) nid =first_node (node_online_map); + prev_nid = nid; +spin_unlock (&nid_lock); + + page =alloc_pages_node (nid,GFP_HIGHUSER |__GFP_COMP|__GFP_NOWARN, +HUGETLB_PAGE_ORDER );if (page) {set_compound_page_dtor (page, free_huge_page);spin_lock (&hugetlb_lock);
Signature · 3 lines
1.5.2.5 --
PATCH 40/58 do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
In reply to Willy TarreauFix a bug in mm/mlock.c on 32-bit architectures that prevents a user from locking more than 4GB of shared memory, or allocating more than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is set to RLIM_INFINITY.
--- mm/mlock.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
mm/mlock.c +4 -1
@@ -233,9 +233,12 @@ int user_shm_lock(size_t size, struct user_struct *user) locked = (size +PAGE_SIZE -1 ) >>PAGE_SHIFT ; lock_limit = current->signal->rlim[RLIMIT_MEMLOCK ].rlim_cur; +if (lock_limit ==RLIM_INFINITY ) + allowed =1 ; lock_limit >>=PAGE_SHIFT ;spin_lock (&shmlock_user_lock); -if (locked + user->locked_shm > lock_limit && !capable (CAP_IPC_LOCK )) +if (!allowed && + locked + user->locked_shm > lock_limit && !capable (CAP_IPC_LOCK )) goto out;get_uid (user); user->locked_shm += locked;
Signature · 3 lines
1.5.2.5 --
PATCH 41/58 drivers/video/macmodes.c:mac_find_mode() mustnt be __devinit
In reply to Willy TarreauIf it's EXPORT_SYMBOL'ed it can't be __devinit.
Reported by Mikael Pettersson.
--- drivers/video/macmodes.c | 5 ++--- drivers/video/macmodes.h | 8 ++++---- 2 files changed, 6 insertions(+), 7 deletions(-)
drivers/video/macmodes.c +2 -3
@@ -369,9 +369,8 @@ EXPORT_SYMBOL(mac_map_monitor_sense);* */ -int __devinit mac_find_mode (struct fb_var_screeninfo *var, -struct fb_info *info,const char *mode_option, -unsigned int default_bpp) +int mac_find_mode (struct fb_var_screeninfo *var,struct fb_info *info, +const char *mode_option,unsigned int default_bpp) {const struct fb_videomode *db =NULL ;unsigned int dbsize =0 ;
drivers/video/macmodes.h +4 -4
@@ -55,10 +55,10 @@ extern int mac_vmode_to_var(int vmode, int cmode,extern int mac_var_to_vmode (const struct fb_var_screeninfo *var,int *vmode,int *cmode);extern int mac_map_monitor_sense (int sense); -extern int __devinit mac_find_mode (struct fb_var_screeninfo *var, -struct fb_info *info, -const char *mode_option, -unsigned int default_bpp); +extern int mac_find_mode (struct fb_var_screeninfo *var, +struct fb_info *info, +const char *mode_option, +unsigned int default_bpp);/*
Signature · 3 lines
1.5.2.5 --
PATCH 42/58 nfsd: fix possible oops on re-insertion of rpcsec_gss modules
In reply to Willy TarreauThe handling of the re-registration case is wrong here; the "test" that was returned from auth_domain_lookup will not be used again, so that reference should be put. And auth_domain_lookup never did anything with "new" in this case, so we should just clean it up ourself.
Thanks to Akinobu Mita for bug report, analysis, and testing.
--- net/sunrpc/auth_gss/svcauth_gss.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-)
net/sunrpc/auth_gss/svcauth_gss.c +5 -4
@@ -760,11 +760,12 @@ svcauth_gss_register_pseudoflavor(u32 pseudoflavor, char * name) new->h.flavour = &svcauthops_gss; new->pseudoflavor = pseudoflavor; + stat =0 ; test =auth_domain_lookup (name, &new->h); -if (test != &new->h) {/* XXX Duplicate registration? */ -auth_domain_put (&new->h); -/* dangling ref-count... */ - goto out; +if (test != &new->h) {/* Duplicate registration */ +auth_domain_put (test); +kfree (new->h.name); + goto out_free_dom; }return 0 ;
Signature · 3 lines
1.5.2.5 --
PATCH 43/58 dm snapshot: permit invalid activation
In reply to Willy TarreauAllow invalid snapshots to be activated instead of failing.
This allows userspace to reinstate any given snapshot state - for example after an unscheduled reboot - and clean up the invalid snapshot at its leisure.
--- drivers/md/dm-exception-store.c | 11 ++++++----- drivers/md/dm-snap.c | 5 ++++- 2 files changed, 10 insertions(+), 6 deletions(-)
drivers/md/dm-exception-store.c +6 -5
@@ -453,11 +453,6 @@ static int persistent_read_metadata(struct exception_store *store)/* * Sanity checks. */ -if (!ps->valid) { -DMWARN ("snapshot is marked invalid" ); -return -EINVAL ; - } -if (ps->version !=SNAPSHOT_DISK_VERSION ) {DMWARN ("unable to handle snapshot disk version %d" , ps->version);
@@ -465,6 +460,12 @@ static int persistent_read_metadata(struct exception_store *store) }/* +* Metadata are valid, but snapshot is invalidated +*/ +if (!ps->valid) +return 1 ; + +/* * Read the metadata. */ r =read_exceptions (ps);
drivers/md/dm-snap.c +4 -1
@@ -522,9 +522,12 @@ static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)/* Metadata must only be loaded into one table at once */ r = s->store.read_metadata (&s->store); -if (r) { +if (r <0 ) { ti->error ="Failed to read snapshot metadata" ; goto bad6; + }else if (r >0 ) { + s->valid =0 ; +DMWARN ("Snapshot is marked invalid." ); }bio_list_init (&s->queued_bios);
Signature · 3 lines
1.5.2.5 --
PATCH 45/58 Hangup TTY before releasing rfcomm_dev
In reply to Willy TarreauThe core problem is that RFCOMM socket layer ioctl can release rfcomm_dev struct while RFCOMM TTY layer is still actively using it. Calling tty_vhangup() is needed for a synchronous hangup before rfcomm_dev is freed.
Addresses the oops at http://bugzilla.kernel.org/show_bug.cgi?id=7509
--- net/bluetooth/rfcomm/tty.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
net/bluetooth/rfcomm/tty.c +4 -0
@@ -381,6 +381,10 @@ static int rfcomm_release_dev(void __user *arg)if (req.flags & (1 <<RFCOMM_HANGUP_NOW ))rfcomm_dlc_close (dev->dlc,0 ); +/* Shut down TTY synchronously before freeing rfcomm_dev */ +if (dev->tty) +tty_vhangup (dev->tty); +rfcomm_dev_del (dev);rfcomm_dev_put (dev);return 0 ;
Signature · 3 lines
1.5.2.5 --
PATCH 46/58 Keep rfcomm_dev on the list until it is freed
In reply to Willy TarreauThis patch changes the RFCOMM TTY release process so that the TTY is kept on the list until it is really freed. A new device flag is used to keep track of released TTYs.
--- include/net/bluetooth/rfcomm.h | 1 + net/bluetooth/rfcomm/tty.c | 30 ++++++++++++++++++++++-------- 2 files changed, 23 insertions(+), 8 deletions(-)
include/net/bluetooth/rfcomm.h +1 -0
@@ -323,6 +323,7 @@ int rfcomm_connect_ind(struct rfcomm_session *s, u8 channel, struct rfcomm_dlc#define RFCOMM_RELEASE_ONHUP 1#define RFCOMM_HANGUP_NOW 2#define RFCOMM_TTY_ATTACHED 3 +#define RFCOMM_TTY_RELEASED 4struct rfcomm_dev_req {s16 dev_id;
net/bluetooth/rfcomm/tty.c +22 -8
@@ -93,6 +93,10 @@ static void rfcomm_dev_destruct(struct rfcomm_dev *dev)BT_DBG ("dev %p dlc %p" , dev, dlc); +write_lock_bh (&rfcomm_dev_lock); +list_del_init (&dev->list); +write_unlock_bh (&rfcomm_dev_lock); +rfcomm_dlc_lock (dlc);/* Detach DLC if it's owned by this dev */ if (dlc->owner == dev)
@@ -154,8 +158,13 @@ static inline struct rfcomm_dev *rfcomm_dev_get(int id)read_lock (&rfcomm_dev_lock); dev =__rfcomm_dev_get (id); -if (dev) -rfcomm_dev_hold (dev); + +if (dev) { +if (test_bit (RFCOMM_TTY_RELEASED , &dev->flags)) + dev =NULL ; +else +rfcomm_dev_hold (dev); + }read_unlock (&rfcomm_dev_lock);
@@ -263,6 +272,12 @@ out:tty_register_device (rfcomm_tty_driver, dev->id,rfcomm_get_device (dev)); +if (IS_ERR (dev->tty_dev)) { +list_del (&dev->list); +kfree (dev); +return PTR_ERR (dev->tty_dev); + } +return dev->id; }
@@ -270,10 +285,7 @@ static void rfcomm_dev_del(struct rfcomm_dev *dev) {BT_DBG ("dev %p" , dev); -write_lock_bh (&rfcomm_dev_lock); -list_del_init (&dev->list); -write_unlock_bh (&rfcomm_dev_lock); - +set_bit (RFCOMM_TTY_RELEASED , &dev->flags);rfcomm_dev_put (dev); }
@@ -327,7 +339,7 @@ static int rfcomm_create_dev(struct sock *sk, void __user *arg)if (copy_from_user (&req, arg,sizeof (req)))return -EFAULT ; -BT_DBG ("sk %p dev_id %id flags 0x%x" , sk, req.dev_id, req.flags); +BT_DBG ("sk %p dev_id %d flags 0x%x" , sk, req.dev_id, req.flags);if (req.flags !=NOCAP_FLAGS && !capable (CAP_NET_ADMIN ))return -EPERM ;
@@ -368,7 +380,7 @@ static int rfcomm_release_dev(void __user *arg)if (copy_from_user (&req, arg,sizeof (req)))return -EFAULT ; -BT_DBG ("dev_id %id flags 0x%x" , req.dev_id, req.flags); +BT_DBG ("dev_id %d flags 0x%x" , req.dev_id, req.flags);if (!(dev =rfcomm_dev_get (req.dev_id)))return -ENODEV ;
@@ -417,6 +429,8 @@ static int rfcomm_get_dev_list(void __user *arg)list_for_each (p, &rfcomm_dev_list) { struct rfcomm_dev *dev = list_entry(p, struct rfcomm_dev, list); +if (test_bit (RFCOMM_TTY_RELEASED , &dev->flags)) +continue ; (di + n)->id = dev->id; (di + n)->flags = dev->flags; (di + n)->state = dev->dlc->state;
Signature · 3 lines
1.5.2.5 --
PATCH 47/58 IPV6: /proc/net/anycast6 unbalanced inet6_dev refcnt
In reply to Willy TarreauReading /proc/net/anycast6 when there is no anycast address on an interface results in an ever-increasing inet6_dev reference count, as well as a reference to the netdevice you can't get rid of.
--- net/ipv6/anycast.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
net/ipv6/anycast.c +1 -0
@@ -67,6 +67,7 @@ ip6_onlink(struct in6_addr *addr, struct net_device *dev)break ; }read_unlock_bh (&idev->lock); +in6_dev_put (idev); }rcu_read_unlock ();return onlink;
Signature · 3 lines
1.5.2.5 --
PATCH 48/58 sx: switch subven and subid values
In reply to Willy Tarreausx.c is failing to locate Graham's card.
--- drivers/char/sx.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
drivers/char/sx.c +2 -2
@@ -2721,9 +2721,9 @@ static void __devexit sx_pci_remove(struct pci_dev *pdev)its because the standard requires it. So check for SUBVENDOR_ID. */ static struct pci_device_id sx_pci_tbl[] = { {PCI_VENDOR_ID_SPECIALIX ,PCI_DEVICE_ID_SPECIALIX_SX_XIO_IO8 , - .subvendor =0x0200 ,.subdevice =PCI_ANY_ID }, + .subvendor =PCI_ANY_ID , .subdevice =0x0200 }, {PCI_VENDOR_ID_SPECIALIX ,PCI_DEVICE_ID_SPECIALIX_SX_XIO_IO8 , - .subvendor =0x0300 ,.subdevice =PCI_ANY_ID }, + .subvendor =PCI_ANY_ID , .subdevice =0x0300 }, {0 } };
Signature · 3 lines
1.5.2.5 --
PATCH 49/58 UML: exports for hostfs
In reply to Willy TarreauAdd some exports for hostfs that are required after Alberto Bertogli's fixes for accessing unlinked host files.
Also did some style cleanups while I was here.
--- arch/um/os-Linux/user_syms.c | 20 ++++++++------------ 1 files changed, 8 insertions(+), 12 deletions(-)
arch/um/os-Linux/user_syms.c +8 -12
@@ -5,7 +5,8 @@* so I *must* declare good prototypes for them and then EXPORT them. * The kernel code uses the macro defined by include/linux/string.h, * so I undef macros; the userspace code does not include that and I -* add an EXPORT for the glibc one.*/ +* add an EXPORT for the glibc one. +*/ #undef strlen#undef strstr
@@ -61,12 +62,18 @@ EXPORT_SYMBOL_PROTO(dup2);EXPORT_SYMBOL_PROTO (__xstat);EXPORT_SYMBOL_PROTO (__lxstat);EXPORT_SYMBOL_PROTO (__lxstat64); +EXPORT_SYMBOL_PROTO (__fxstat64);EXPORT_SYMBOL_PROTO (lseek);EXPORT_SYMBOL_PROTO (lseek64);EXPORT_SYMBOL_PROTO (chown); +EXPORT_SYMBOL_PROTO (fchown);EXPORT_SYMBOL_PROTO (truncate); +EXPORT_SYMBOL_PROTO (ftruncate64);EXPORT_SYMBOL_PROTO (utime); +EXPORT_SYMBOL_PROTO (utimes); +EXPORT_SYMBOL_PROTO (futimes);EXPORT_SYMBOL_PROTO (chmod); +EXPORT_SYMBOL_PROTO (fchmod);EXPORT_SYMBOL_PROTO (rename);EXPORT_SYMBOL_PROTO (__xmknod);
@@ -102,14 +109,3 @@ EXPORT_SYMBOL(__stack_smash_handler); extern long __guard __attribute__((weak));EXPORT_SYMBOL (__guard ); - -/* -* Overrides for Emacs so that we follow Linus's tabbing style. -* Emacs will notice this stuff at the end of the file and automatically -* adjust the settings for this buffer only. This must remain at the end -* of the file. -* --------------------------------------------------------------------------- -* Local variables: -* c-file-style: "linux" -* End: -*/
Signature · 3 lines
1.5.2.5 --
PATCH 50/58 random: fix bound check ordering (CVE-2007-3105)
In reply to Willy TarreauIf root raised the default wakeup threshold over the size of the output pool, the pool transfer function could overflow the stack with RNG bytes, causing a DoS or potential privilege escalation.
(Bug reported by the PaX Team <[email protected]>)
--- drivers/char/random.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-)
drivers/char/random.c +7 -2
@@ -693,9 +693,14 @@ static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes) if (r->pull && r->entropy_count < nbytes * 8 && r->entropy_count < r->poolinfo->POOLBITS) { - int bytes = max_t(int, random_read_wakeup_thresh / 8, - min_t(int, nbytes, sizeof(tmp))); + /* If we're limited, always leave two wakeup worth's BITS */ int rsvd = r->limit ? 0 : random_read_wakeup_thresh/4; + int bytes = nbytes; + + /* pull at least as many as BYTES as wakeup BITS */ + bytes = max_t(int, bytes, random_read_wakeup_thresh / 8); + /* but never more than the buffer size */ + bytes = min_t(int, bytes, sizeof(tmp)); DEBUG_ENT("going to reseed %s with %d bits " "(%d of %d requested)
",
Signature · 3 lines
1.5.2.5 --
PATCH 51/58 softmac: Fix deadlock of wx_set_essid with assoc work
In reply to Willy TarreauThe essid wireless extension does deadlock against the assoc mutex, as we don't unlock the assoc mutex when flushing the workqueue, which also holds the lock.
--- net/ieee80211/softmac/ieee80211softmac_wx.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-)
net/ieee80211/softmac/ieee80211softmac_wx.c +8 -3
@@ -74,8 +74,8 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,struct ieee80211softmac_auth_queue_item *authptr;int length =0 ; +check_assoc_again:mutex_lock (&sm->associnfo.mutex); -/* Check if we're already associating to this or another network * If it's another network, cancel and start over with our new network * If it's our network, ignore the change, we're already doing it!
@@ -98,13 +98,18 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,cancel_delayed_work (&authptr->work); sm->associnfo.bssvalid =0 ; sm->associnfo.bssfixed =0 ; -flush_scheduled_work (); sm->associnfo.associating =0 ; sm->associnfo.associated =0 ; +/* We must unlock to avoid deadlocks with the assoc workqueue +* on the associnfo.mutex */ +mutex_unlock (&sm->associnfo.mutex); +flush_scheduled_work (); +/* Avoid race! Check assoc status again. Maybe someone started an +* association while we flushed. */ + goto check_assoc_again; } } - sm->associnfo.static_essid =0 ; sm->associnfo.assoc_wait =0 ;
Signature · 3 lines
1.5.2.5 --
PATCH 52/58 ata_piix: update map 10b for ich8m
In reply to Willy TarreauFix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m.
--- drivers/ata/ata_piix.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/ata/ata_piix.c +1 -1
@@ -431,7 +431,7 @@ static const struct piix_map_db ich8_map_db = {/* PM PS SM SS MAP */ { P0, P2, P1, P3 }, /* 00b (hardwired when in AHCI) */ { RV, RV, RV, RV }, - { IDE, IDE, NA, NA }, /* 10b (IDE mode) */ + { P0, P2, IDE, IDE }, /* 10b (IDE mode) */ { RV, RV, RV, RV }, }, };
Signature · 3 lines
1.5.2.5 --
PATCH 53/58 direct-io: fix error-path crashes
In reply to Willy TarreauNeed to initialize map_bh.b_state to zero. Otherwise, in case of a faulty user-buffer its possible to go into dio_zero_block() and submit a page by mistake - since it checks for buffer_new().
http://marc.info/?l=linux-kernel&m=118551339032528&w=2
akpm: Linus had a (better) patch to just do a kzalloc() in there, but it got lost. Probably this version is better for -stable anwyay.
--- fs/direct-io.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
fs/direct-io.c +1 -0
@@ -978,6 +978,7 @@ direct_io_worker(int rw, struct kiocb *iocb, struct inode *inode, dio->get_block = get_block; dio->end_io = end_io; dio->map_bh.b_private =NULL ; + dio->map_bh.b_state =0 ; dio->final_block_in_bio =-1 ; dio->next_block_for_io =-1 ;
Signature · 3 lines
1.5.2.5 --
PATCH 54/58 stifb: detect cards in double buffer mode more reliably
In reply to Willy TarreauVisualize-EG, Graffiti and A4450A graphics cards on PARISC can be configured in double-buffer and standard mode, but the stifb driver supports standard mode only.
This patch detects double-buffered cards more reliable.
It is a real bugfix for a very nasty problem for all parisc users which have wrongly configured their graphic card. The problem: The stifb graphics driver will not detect that the card is wrongly configured and then nevertheless just enables the graphics mode, which it shouldn't. In the end, the user will see no further updates / boot messages on the screen.
We had documented this problem already on our FAQ
(http://parisc-linux.org/faq/index.html#viseg "Why do I get corrupted graphics with my Vis-EG/Graffiti/A4450A card?") but people still run into this problem.
So having this fix in as early as possible can help us.
--- drivers/video/stifb.c | 19 ++++++++++++------- 1 files changed, 12 insertions(+), 7 deletions(-)
drivers/video/stifb.c +0 -7
@@ -1101,13 +1101,18 @@ stifb_init_fb(struct sti_struct *sti, int bpp_pref)/* only supported cards are allowed */ switch (fb->id) {case CRT_ID_VISUALIZE_EG : - /* look for a double buffering device like e.g. the - "INTERNAL_EG_DX1024" in the RDI precisionbook laptop - which won't work. The same device in non-double - buffering mode returns "INTERNAL_EG_X1024". */ - if (strstr(sti->outptr.dev_name, "EG_DX")) { - printk(KERN_WARNING - "stifb: ignoring '%s'. Disable double buffering in IPL menu.
",
+ /* Visualize cards can run either in "double buffer" or
+ "standard" mode. Depending on the mode, the card reports
+ a different device name, e.g. "INTERNAL_EG_DX1024" in double + buffer mode and "INTERNAL_EG_X1024" in standard mode. + Since this driver only supports standard mode, we check + if the device name contains the string "DX" and tell the + user how to reconfigure the card. */
+ if (strstr(sti->outptr.dev_name, "DX")) {
+ printk(KERN_WARNING "WARNING: stifb framebuffer driver does not "
+ "support '%s' in double-buffer mode.
"
+ KERN_WARNING "WARNING: Please disable the double-buffer mode "
+ "in IPL menu (the PARISC-BIOS).
",
sti->outptr.dev_name);
goto out_err0;
}
Signature · 3 lines
1.5.2.5 --
PATCH 55/58 pata_atiixp: add SB700 PCI ID
In reply to Willy Tarreau[libata] pata_atiixp: add SB700 PCI ID
Quoted 1 line
From AMD.
--- drivers/ata/pata_atiixp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
drivers/ata/pata_atiixp.c +1 -0
@@ -283,6 +283,7 @@ static const struct pci_device_id atiixp[] = { { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP300_IDE), }, { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP400_IDE), }, { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP600_IDE), }, + { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP700_IDE), }, { }, };
Signature · 3 lines
1.5.2.5 --
PATCH 57/58 CPUFREQ: ondemand: add a check to avoid negative load calculation
In reply to Willy TarreauDue to rounding and inexact jiffy accounting, idle_ticks can sometimes be higher than total_ticks. Make sure those cases are handled as zero load case.
--- drivers/cpufreq/cpufreq_ondemand.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/cpufreq/cpufreq_ondemand.c +3 -2
@@ -334,7 +334,7 @@ static struct attribute_group dbs_attr_group = {static void dbs_check_cpu (struct cpu_dbs_info_s *this_dbs_info) {unsigned int idle_ticks, total_ticks; -unsigned int load; +unsigned int load =0 ;cputime64_t cur_jiffies;struct cpufreq_policy *policy;
@@ -380,7 +380,8 @@ static void dbs_check_cpu(struct cpu_dbs_info_s *this_dbs_info)if (tmp_idle_ticks < idle_ticks) idle_ticks = tmp_idle_ticks; } - load = (100 * (total_ticks - idle_ticks)) / total_ticks; +if (likely (total_ticks > idle_ticks)) + load = (100 * (total_ticks - idle_ticks)) / total_ticks;/* Check for frequency increase */ if (load > dbs_tuners_ins.up_threshold) {
Signature · 3 lines
1.5.2.5 --
PATCH 58/58 Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848)
In reply to Willy TarreauThis fixes a vulnerability in the "parent process death signal" implementation discoverd by Wojciech Purczynski of COSEINC PTE Ltd. and iSEC Security Research.
http://marc.info/?l=bugtraq&m=118711306802632&w=2
--- fs/exec.c | 13 +++++++++---- 1 files changed, 9 insertions(+), 4 deletions(-)
fs/exec.c +9 -4
@@ -881,9 +881,12 @@ int flush_old_exec(struct linux_binprm * bprm)*/ current->mm->task_size =TASK_SIZE ; -if (bprm->e_uid != current->euid || bprm->e_gid != current->egid || -file_permission (bprm->file,MAY_READ ) || - (bprm->interp_flags &BINPRM_FLAGS_ENFORCE_NONDUMP )) { +if (bprm->e_uid != current->euid || bprm->e_gid != current->egid) { +suid_keys (current); + current->mm->dumpable = suid_dumpable; + current->pdeath_signal =0 ; + }else if (file_permission (bprm->file,MAY_READ ) || + (bprm->interp_flags &BINPRM_FLAGS_ENFORCE_NONDUMP )) {suid_keys (current); current->mm->dumpable = suid_dumpable; }
@@ -974,8 +977,10 @@ void compute_creds(struct linux_binprm *bprm) {int unsafe; -if (bprm->e_uid != current->uid) +if (bprm->e_uid != current->uid) {suid_keys (current); + current->pdeath_signal =0 ; + }exec_keys (current);task_lock (current);
Signature · 3 lines
1.5.2.5 --
Hi Willy,
Quoted 9 lines · Willy Tarreau
This is the start of the review cycle for the stable 2.6.20.17 kernel release. This version catches up with 2.6.22.4, and 58 patches will be posted as a response to this message.
The following security issues are solved :
CVE-2007-3105
CVE-2007-3848
CVE-2007-3851
Quoted 5 lines
The rolled up patch can be found here :
ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gzResponses should be made by August 24, 2007, 19:00:00 UTC. Anything received after that time might be too late.
I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
rpm -qa selinux-policy*
selinux-policy-devel-2.6.4-33.fc7
selinux-policy-2.6.4-33.fc7
selinux-policy-targeted-2.6.4-33.fc7
I didn't tested 2.6.20.* since 2.6.20 release so it might take some time to figure out.
Regards,
Michal
Signature · 2 lines
LOG http://www.stardust.webpages.pl/log/
Hi Michal,
Quoted 22 lines · Michal Piotrowski
Hi Willy,
Quoted 9 lines · Willy Tarreau
This is the start of the review cycle for the stable 2.6.20.17 kernel release. This version catches up with 2.6.22.4, and 58 patches will be posted as a response to this message.
The following security issues are solved :
CVE-2007-3105
CVE-2007-3848
CVE-2007-3851Quoted 5 lines
The rolled up patch can be found here :
ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gzResponses should be made by August 24, 2007, 19:00:00 UTC. Anything received after that time might be too late.
I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
Quoted 7 lines
rpm -qa selinux-policy*
selinux-policy-devel-2.6.4-33.fc7
selinux-policy-2.6.4-33.fc7
selinux-policy-targeted-2.6.4-33.fc7I didn't tested 2.6.20.* since 2.6.20 release so it might take some time to figure out.
I'm a total looser in selinux, so I'll not be able to help here. Could you please test if 2.6.20.16 works ? It would at least tell us if it's one of the patches in 17-rc1.
Thanks,
Willy
Quoted 3 lines · Michal Piotrowski
I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
Please setCONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n
You don't have complete policy for the new network controls, which are not enabled by default and not integreated fully into distros yet.
Signature · 2 lines
James Morris <[email protected]>
Quoted 11 lines · James Morris
Quoted 3 lines · Michal Piotrowski
I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-configPlease set
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=nYou don't have complete policy for the new network controls, which are not enabled by default and not integreated fully into distros yet.
Actually, this looks to be a bug where the secmark field of the skb is not being initialized correctly. Patch coming soon...
Signature · 2 lines
James Morris <[email protected]>
Quoted 11 lines · James Morris
Quoted 3 lines · Michal Piotrowski
I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-configPlease set
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=nYou don't have complete policy for the new network controls, which are not enabled by default and not integreated fully into distros yet.
Still, that denial shouldn't be against kernel_t unless he has iptables SECMARK rules that assign that value.
It's the change to the skb allocator - no longer clears up through truesize and thus secmark is garbage initially. That would apply to mainline too.
Signature · 2 lines
Stephen Smalley National Security Agency
Quoted 13 lines · Stephen Smalley
Quoted 11 lines · James Morris
Quoted 3 lines · Michal Piotrowski
I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-configPlease set
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=nYou don't have complete policy for the new network controls, which are not enabled by default and not integreated fully into distros yet.
Quoted 6 lines
Still, that denial shouldn't be against
kernel_tunless he has iptables SECMARK rules that assign that value.It's the change to the skb allocator - no longer clears up through truesize and thus secmark is garbage initially. That would apply to mainline too.
Oops, never mind - tail still follows secmark, so that shouldn't matter. So I'm not sure why we are getting a bad value for secmark here - should be initialized to zero and never modified unless there is an iptables secmark rule.
Signature · 2 lines
Stephen Smalley National Security Agency
Quoted 4 lines · Stephen Smalley
Oops, never mind - tail still follows secmark, so that shouldn't matter. So I'm not sure why we are getting a bad value for secmark here - should be initialized to zero and never modified unless there is an iptables secmark rule.
Michal, do you see this in current git?
Signature · 2 lines
James Morris <[email protected]>
Quoted 8 lines · James Morris
Quoted 4 lines · Stephen Smalley
Oops, never mind - tail still follows secmark, so that shouldn't matter. So I'm not sure why we are getting a bad value for secmark here - should be initialized to zero and never modified unless there is an iptables secmark rule.
Michal, do you see this in current git?
No, I do not see this problem in 2.6.23. I had similar problem last month, but it is fixed now.
http://lkml.org/lkml/2007/7/12/362
Regards,
Michal
Signature · 2 lines
LOG http://www.stardust.webpages.pl/log/
Quoted 8 lines · Michal Piotrowski
Quoted 7 lines · James Morris
Quoted 4 lines · Stephen Smalley
Oops, never mind - tail still follows secmark, so that shouldn't matter. So I'm not sure why we are getting a bad value for secmark here - should be initialized to zero and never modified unless there is an iptables secmark rule.
Quoted 6 lines
Quoted 1 line
Michal, do you see this in current git?
No, I do not see this problem in 2.6.23. I had similar problem last month, but it is fixed now.
The difference being that there the denials were against unlabeled_t (the expected default in the presence of no iptables SECMARK rules, and allowed by current policies), while the denials against 2.6.20.17 were against kernel_t. Which shouldn't ever happen unless you have an iptables SECMARK rule that assigns that value to a packet. So this is a different issue. BTW, the fact that it is showing up as kernel_t means that skb->secmark == SECINITSID_KERNEL == 1, FWIW. Whereas it should be zero in the absence of iptables rules that set it.
Signature · 2 lines
Stephen Smalley National Security Agency
Quoted 8 lines · Michal Piotrowski
Quoted 7 lines · James Morris
Quoted 4 lines · Stephen Smalley
Oops, never mind - tail still follows secmark, so that shouldn't matter. So I'm not sure why we are getting a bad value for secmark here - should be initialized to zero and never modified unless there is an iptables secmark rule.
Quoted 6 lines
Quoted 1 line
Michal, do you see this in current git?
No, I do not see this problem in 2.6.23. I had similar problem last month, but it is fixed now.
The previous problem is theoretically unrelated. It arose via a separate mechanism which can't be used at the same as the one you're seeing now in the logs.
So this either looks like a problem which has gone unnoticed and was inadvertently fixed at some point, or is unique to the 2.6.20 stable series.
- James
Signature · 2 lines
James Morris <[email protected]>
Quoted 17 lines · James Morris
Quoted 8 lines · Michal Piotrowski
Quoted 7 lines · James Morris
Quoted 4 lines · Stephen Smalley
Oops, never mind - tail still follows secmark, so that shouldn't matter. So I'm not sure why we are getting a bad value for secmark here - should be initialized to zero and never modified unless there is an iptables secmark rule.
Quoted 6 lines
Quoted 1 line
Michal, do you see this in current git?
No, I do not see this problem in 2.6.23. I had similar problem last month, but it is fixed now.
Quoted 7 lines
The previous problem is theoretically unrelated. It arose via a separate mechanism which can't be used at the same as the one you're seeing now in the logs.
So this either looks like a problem which has gone unnoticed and was inadvertently fixed at some point, or is unique to the 2.6.20 stable series.
Yup, it is very interesting why no one noticed it. Binary search in progress:
good - 2.6.20.4
bad - 2.6.20.8
Regards,
Michal
Signature · 2 lines
LOG http://www.stardust.webpages.pl/log/
Quoted 1 line · Michal Piotrowski
Yup, it is very interesting why no one noticed it.
The new network controls are not enabled by default yet in distros.
- James
Signature · 2 lines
James Morris <[email protected]>
Quoted 5 lines · James Morris
Quoted 1 line · Michal Piotrowski
Yup, it is very interesting why no one noticed it.
The new network controls are not enabled by default yet in distros.
That's why I enable most of these unsupported features :)
Unfortunately, I don't have time to test all stable/development releases.
Regards,
Michal
Signature · 2 lines
LOG http://www.stardust.webpages.pl/log/
Quoted 1 line · Michal Piotrowski
On 22/08/07, James Morris <[email protected]> wrote:
[snip]
Quoted 11 lines
Quoted 7 lines
The previous problem is theoretically unrelated. It arose via a separate mechanism which can't be used at the same as the one you're seeing now in the logs.
So this either looks like a problem which has gone unnoticed and was inadvertently fixed at some point, or is unique to the 2.6.20 stable series.
Yup, it is very interesting why no one noticed it. Binary search in progress:
good - 2.6.20.4
bad - 2.6.20.8
Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
any suggestions?
I also have seen this avc on 2.6.20.6 during reboot
[ 2333.905944] audit(1187803699.273:271): avc: denied { send } for
saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
scontext=user_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=packet
[ 2334.420598] audit(1187803699.789:272): avc: denied { send } forsaddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet
so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
Regards,
Michal
Signature · 2 lines
LOG http://www.stardust.webpages.pl/log/
Quoted 26 lines · Michal Piotrowski
Quoted 1 line · Michal Piotrowski
On 22/08/07, James Morris <[email protected]> wrote:
[snip]
Quoted 11 lines
Quoted 7 lines
The previous problem is theoretically unrelated. It arose via a separate mechanism which can't be used at the same as the one you're seeing now in the logs.
So this either looks like a problem which has gone unnoticed and was inadvertently fixed at some point, or is unique to the 2.6.20 stable series.
Yup, it is very interesting why no one noticed it. Binary search in progress:
good - 2.6.20.4
bad - 2.6.20.8Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
any suggestions?I also have seen this avc on 2.6.20.6 during reboot
[ 2333.905944] audit(1187803699.273:271): avc: denied { send } for saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet [ 2334.420598] audit(1187803699.789:272): avc: denied { send } for
Quoted 7 lines
saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet
so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
Might be related to this:
http://marc.info/?l=git-commits-head&m=118271540932264&w=2
Signature · 2 lines
Stephen Smalley National Security Agency
Willy Tarreau
Acked-by James MorrisQuoted 31 lines · Stephen Smalley
Quoted 30 lines · Michal Piotrowski
Quoted 1 line · Michal Piotrowski
On 22/08/07, James Morris <[email protected]> wrote:
[snip]
Quoted 11 lines
Quoted 7 lines
The previous problem is theoretically unrelated. It arose via a separate mechanism which can't be used at the same as the one you're seeing now in the logs.
So this either looks like a problem which has gone unnoticed and was inadvertently fixed at some point, or is unique to the 2.6.20 stable series.
Yup, it is very interesting why no one noticed it. Binary search in progress:
good - 2.6.20.4
bad - 2.6.20.8Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
any suggestions?I also have seen this avc on 2.6.20.6 during reboot
[ 2333.905944] audit(1187803699.273:271): avc: denied { send } for saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet [ 2334.420598] audit(1187803699.789:272): avc: denied { send } forsaddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet
Quoted 6 lines
Quoted 3 lines
so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
Might be related to this:
http://marc.info/?l=git-commits-head&m=118271540932264&w=2
Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20 nor in 2.6.21. Michal, could you please try to apply the patch ? I include it here for your convenience. If it fixes your problem, I can queue it for next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case Greg and Chris plan to release another one.
From: Patrick McHardy <[email protected]>
Date: Sun, 24 Jun 2007 05:58:34 +0000 (-0700)
Subject: [SKBUFF]: Fix incorrect config #ifdef around skb_copy_secmark
X-Git-Tag: v2.6.22~103^2~6
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=dbbeb2f9917792b989b6269ebfe24257f9aa1618
[SKBUFF]: Fix incorrect config #ifdef around skb_copy_secmark
secmark doesn't depend on CONFIG_NET_SCHED.
---
net/core/skbuff.c +1 -1
@@ -434,8 +434,8 @@ struct sk_buff *skb_clone(struct sk_buff *skb, gfp_t gfp_mask) n->tc_verd =CLR_TC_MUNGED (n->tc_verd);C (iif);#endif -skb_copy_secmark (n, skb);#endif +skb_copy_secmark (n, skb);C (truesize);atomic_set (&n->users,1 );C (head);
Thanks,
Willy
Willy Tarreau pisze:
Quoted 33 lines · Stephen Smalley
Quoted 32 lines · Michal Piotrowski
Quoted 31 lines · Michal Piotrowski
Quoted 1 line · James Morris
[snip]
Quoted 10 lines
Quoted 7 lines
The previous problem is theoretically unrelated. It arose via a separate mechanism which can't be used at the same as the one you're seeing now in the logs.
So this either looks like a problem which has gone unnoticed and was inadvertently fixed at some point, or is unique to the 2.6.20 stable series.
Yup, it is very interesting why no one noticed it. Binary search in progress:
good - 2.6.20.4
bad - 2.6.20.8Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
any suggestions?I also have seen this avc on 2.6.20.6 during reboot
[ 2333.905944] audit(1187803699.273:271): avc: denied { send } for saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet [ 2334.420598] audit(1187803699.789:272): avc: denied { send } forsaddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet
so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
Quoted 9 lines
Quoted 2 lines
Might be related to this:
http://marc.info/?l=git-commits-head&m=118271540932264&w=2Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20 nor in 2.6.21. Michal, could you please try to apply the patch ? I include it here for your convenience. If it fixes your problem, I can queue it for next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case Greg and Chris plan to release another one.
I confirm that this patch fixes the problem.
Regards,
Michal
Signature · 2 lines
LOG http://www.stardust.webpages.pl/log/
Quoted 37 lines · Michal Piotrowski
Willy Tarreau pisze:
Quoted 36 lines · Stephen Smalley
Quoted 34 lines · Michal Piotrowski
Quoted 24 lines · Michal Piotrowski
Quoted 1 line · James Morris
[snip]
Quoted 10 lines
Quoted 7 lines
The previous problem is theoretically unrelated. It arose via a separate mechanism which can't be used at the same as the one you're seeing now in the logs.
So this either looks like a problem which has gone unnoticed and was inadvertently fixed at some point, or is unique to the 2.6.20 stable series.
Yup, it is very interesting why no one noticed it. Binary search in progress:
good - 2.6.20.4
bad - 2.6.20.8Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
any suggestions?I also have seen this avc on 2.6.20.6 during reboot
[ 2333.905944] audit(1187803699.273:271): avc: denied { send } for saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet [ 2334.420598] audit(1187803699.789:272): avc: denied { send } forQuoted 7 lines
saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=packet
so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
Might be related to this:
http://marc.info/?l=git-commits-head&m=118271540932264&w=2
Quoted 8 lines
Quoted 6 lines
Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20 nor in 2.6.21. Michal, could you please try to apply the patch ? I include it here for your convenience. If it fixes your problem, I can queue it for next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case Greg and Chris plan to release another one.
I confirm that this patch fixes the problem.
Perfect, thanks for your fast feedback, it is really appreciated ! I'm queuing it for 2.6.20.18.
Regards,
Willy