twitter: linux.kernel - 25 new messages in 19 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Warning in ath9k after update from 2.6.33.1 to 2.6.33.2 - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/8485a733b10ef98c?hl=en
* viafb: use proper pci config API - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/23b4594cab6fc77b?hl=en
* staging: et131x: et1310_eeprom.c coding style fixes. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/69accf0878939308?hl=en
* viafb: Do not probe for LVDS/TMDS on OLPC XO-1.5 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/89505add244b30dc?hl=en
* staging: et131x: et1310_phy.c coding style fixes. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/977c019ef0a0a46b?hl=en
* setitimer vs. threads: SIGALRM returned to which thread? (process master or
individual child) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0c5f95c047f602a1?hl=en
* rmap: make anon_vma_prepare link in all the anon_vmas of a mergeable VMA - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/eec470a501781823?hl=en
* Kernel crash in xfs_iflush_cluster (was Somebody take a look please!...) - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/31111d6646356936?hl=en
* rcu: add rcu_access_pointer and rcu_dereference_protected - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/21441064d06b7f4d?hl=en
* proc: make task_sig() lockless - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5598dbf16865e26b?hl=en
* USB transfer_buffer allocations on 64bit systems - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a96a33ce18e828e9?hl=en
* 2.6.34-rc3 doesn't suspend to disk (-rc2 did) - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/88d031f36fa07259?hl=en
* Probing System calls - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/01e4b7f90a084e6b?hl=en
* 2.6.31 regression: programs crashing after a couple of days of uptime with
hibernation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c57662f68a76c20d?hl=en
* MTD: Suppress warnings in inline_map_read() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9f6eabab93c6a5e5?hl=en
* Linux 2.6.34-rc3 + CAN build problem - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/4a588016aca1bbac?hl=en
* Add "nested" field to event of lock_release - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/241df274c77cdce0?hl=en
* Question about lock sequence - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/96b38e24ca76f796?hl=en
* tcp: add setsockopt to disable slow start after idle - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7e8dc919f86384a9?hl=en

==============================================================================
TOPIC: Warning in ath9k after update from 2.6.33.1 to 2.6.33.2
http://groups.google.com/group/linux.kernel/t/8485a733b10ef98c?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 12:00 am
From: Johannes Berg

On Fri, 2010-04-09 at 19:21 +0200, Thomas Bächler wrote:
> Since I upgraded from 2.6.33.1 to .2, I get the following warning
> sometimes, related to wireless:
>
> ------------[ cut here ]------------
> WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x82/0xb0()
> Hardware name: TECRA A11
> Modules linked in: ipv6 rfcomm sco bnep l2cap bridge stp llc
> cpufreq_ondemand tun ext3 jbd btusb bluetooth uvcvideo videodev
> snd_seq_dummy v4l1_compat arc4 snd_seq_oss ecb v4l2_compat_ioctl32
> snd_seq_midi_event snd_hda_codec_intelhdmi snd_seq snd_seq_device
> tpm_infineon snd_hda_codec_realtek ath9k snd_pcm_oss ath9k_common
> snd_mixer_oss snd_hda_intel snd_hda_codec mac80211 snd_hwdep snd_pcm
> snd_timer ath9k_hw snd joydev soundcore ath sdhci_pci kvm_intel
> snd_page_alloc ehci_hcd iTCO_wdt evdev sdhci iTCO_vendor_support kvm
> usbcore mmc_core e1000e psmouse tpm_tis cfg80211 tpm toshiba_acpi
> acpi_cpufreq led_class tpm_bios rfkill toshiba_bluetooth serio_raw
> pcspkr sr_mod thermal cdrom battery sg ac freq_table processor rtc_cmos
> rtc_core rtc_lib fpu aesni_intel cryptd aes_x86_64 aes_generic xts
> gf128mul dm_crypt dm_mod sd_mod ahci libata scsi_mod ext4 mbcache jbd2
> crc16 i915 drm_kms_helper drm i2c_algo_bit button i2c_core video output
> intel_agp [last unloaded: microcode]
> Pid: 2571, comm: wpa_supplicant Not tainted 2.6.33-ARCH #1
> Call Trace:
> [<ffffffff81052a08>] warn_slowpath_common+0x78/0xb0
> [<ffffffff81052a4f>] warn_slowpath_null+0xf/0x20
> [<ffffffff81059682>] local_bh_enable_ip+0x82/0xb0
> [<ffffffff8135d42f>] _raw_spin_unlock_bh+0x1f/0x30
> [<ffffffffa04018ed>] ath_tx_node_cleanup+0x19d/0x1c0 [ath9k]
> [<ffffffffa03fc607>] ath9k_sta_notify+0x57/0xb0 [ath9k]
> [<ffffffffa039bbc4>] __sta_info_unlink+0x174/0x220 [mac80211]
> [<ffffffffa039bca8>] sta_info_unlink+0x38/0x60 [mac80211]
> [<ffffffffa03a2639>] ieee80211_set_disassoc+0x1e9/0x290 [mac80211]
> [<ffffffffa03a2e89>] ieee80211_mgd_deauth+0x159/0x160 [mac80211]
> [<ffffffff8104d700>] ? default_wake_function+0x0/0x10
> [<ffffffffa03a9b69>] ieee80211_deauth+0x19/0x20 [mac80211]
> [<ffffffffa02426de>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
> [<ffffffff8135baad>] ? __mutex_lock_slowpath+0x26d/0x370
> [<ffffffffa0246839>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
> [<ffffffffa0248f9c>] cfg80211_wext_siwmlme+0x8c/0xa0 [cfg80211]
> [<ffffffff8133e6b7>] ioctl_standard_iw_point+0x207/0x3a0
> [<ffffffffa0248f10>] ? cfg80211_wext_siwmlme+0x0/0xa0 [cfg80211]
> [<ffffffff8133e850>] ? ioctl_standard_call+0x0/0xd0
> [<ffffffff8133e8e9>] ioctl_standard_call+0x99/0xd0
> [<ffffffff812b2660>] ? __dev_get_by_name+0xa0/0xc0
> [<ffffffff8133dce7>] wext_ioctl_dispatch+0x1f7/0x210
> [<ffffffff8133f330>] ? ioctl_private_call+0x0/0xa0
> [<ffffffff8133de91>] wext_handle_ioctl+0x41/0x90
> [<ffffffff812b8299>] dev_ioctl+0x679/0x850
> [<ffffffff812a0522>] sock_ioctl+0xe2/0x290
> [<ffffffff812a369d>] ? sys_recvfrom+0x13d/0x160
> [<ffffffff811324c8>] vfs_ioctl+0x38/0xd0
> [<ffffffff81132670>] do_vfs_ioctl+0x80/0x560
> [<ffffffff81132bd1>] sys_ioctl+0x81/0xa0
> [<ffffffff8100b1f9>] ? do_device_not_available+0x9/0x10
> [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
> ---[ end trace 8dbf12cb72787a6d ]---

I think the problem is that the locking for sta_notify changed, and a
patch that was written for the new locking was backported to the old,
irq-disabled, locking.

johannes

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

== 2 of 2 ==
Date: Sat, Apr 10 2010 4:20 am
From: Thomas Bächler

Am 10.04.2010 05:21, schrieb Ming Lei:
>> ------------[ cut here ]------------
>> WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x82/0xb0()
>> Hardware name: TECRA A11
>> Modules linked in: ipv6 rfcomm sco bnep l2cap bridge stp llc
>> cpufreq_ondemand tun ext3 jbd btusb bluetooth uvcvideo videodev
>> snd_seq_dummy v4l1_compat arc4 snd_seq_oss ecb v4l2_compat_ioctl32
>> snd_seq_midi_event snd_hda_codec_intelhdmi snd_seq snd_seq_device
>> tpm_infineon snd_hda_codec_realtek ath9k snd_pcm_oss ath9k_common
>> snd_mixer_oss snd_hda_intel snd_hda_codec mac80211 snd_hwdep snd_pcm
>> snd_timer ath9k_hw snd joydev soundcore ath sdhci_pci kvm_intel
>> snd_page_alloc ehci_hcd iTCO_wdt evdev sdhci iTCO_vendor_support kvm
>> usbcore mmc_core e1000e psmouse tpm_tis cfg80211 tpm toshiba_acpi
>> acpi_cpufreq led_class tpm_bios rfkill toshiba_bluetooth serio_raw
>> pcspkr sr_mod thermal cdrom battery sg ac freq_table processor rtc_cmos
>> rtc_core rtc_lib fpu aesni_intel cryptd aes_x86_64 aes_generic xts
>> gf128mul dm_crypt dm_mod sd_mod ahci libata scsi_mod ext4 mbcache jbd2
>> crc16 i915 drm_kms_helper drm i2c_algo_bit button i2c_core video output
>> intel_agp [last unloaded: microcode]
>> Pid: 2571, comm: wpa_supplicant Not tainted 2.6.33-ARCH #1
>> Call Trace:
>> [<ffffffff81052a08>] warn_slowpath_common+0x78/0xb0
>> [<ffffffff81052a4f>] warn_slowpath_null+0xf/0x20
>> [<ffffffff81059682>] local_bh_enable_ip+0x82/0xb0
>> [<ffffffff8135d42f>] _raw_spin_unlock_bh+0x1f/0x30
>> [<ffffffffa04018ed>] ath_tx_node_cleanup+0x19d/0x1c0 [ath9k]
>> [<ffffffffa03fc607>] ath9k_sta_notify+0x57/0xb0 [ath9k]
>> [<ffffffffa039bbc4>] __sta_info_unlink+0x174/0x220 [mac80211]
>> [<ffffffffa039bca8>] sta_info_unlink+0x38/0x60 [mac80211]
>> [<ffffffffa03a2639>] ieee80211_set_disassoc+0x1e9/0x290 [mac80211]
>> [<ffffffffa03a2e89>] ieee80211_mgd_deauth+0x159/0x160 [mac80211]
>> [<ffffffff8104d700>] ? default_wake_function+0x0/0x10
>> [<ffffffffa03a9b69>] ieee80211_deauth+0x19/0x20 [mac80211]
>> [<ffffffffa02426de>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
>> [<ffffffff8135baad>] ? __mutex_lock_slowpath+0x26d/0x370
>> [<ffffffffa0246839>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
>> [<ffffffffa0248f9c>] cfg80211_wext_siwmlme+0x8c/0xa0 [cfg80211]
>> [<ffffffff8133e6b7>] ioctl_standard_iw_point+0x207/0x3a0
>> [<ffffffffa0248f10>] ? cfg80211_wext_siwmlme+0x0/0xa0 [cfg80211]
>> [<ffffffff8133e850>] ? ioctl_standard_call+0x0/0xd0
>> [<ffffffff8133e8e9>] ioctl_standard_call+0x99/0xd0
>> [<ffffffff812b2660>] ? __dev_get_by_name+0xa0/0xc0
>> [<ffffffff8133dce7>] wext_ioctl_dispatch+0x1f7/0x210
>> [<ffffffff8133f330>] ? ioctl_private_call+0x0/0xa0
>> [<ffffffff8133de91>] wext_handle_ioctl+0x41/0x90
>> [<ffffffff812b8299>] dev_ioctl+0x679/0x850
>> [<ffffffff812a0522>] sock_ioctl+0xe2/0x290
>> [<ffffffff812a369d>] ? sys_recvfrom+0x13d/0x160
>> [<ffffffff811324c8>] vfs_ioctl+0x38/0xd0
>> [<ffffffff81132670>] do_vfs_ioctl+0x80/0x560
>> [<ffffffff81132bd1>] sys_ioctl+0x81/0xa0
>> [<ffffffff8100b1f9>] ? do_device_not_available+0x9/0x10
>> [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
>> ---[ end trace 8dbf12cb72787a6d ]---
>>
>> This machine is an Intel Core i5-520M running x86_64, wireless is ath9k.
>>
>>
>
> I does not find the issue on 2.6.34-rc3-wireless-next, using wext and trigger
> a disassociation.
>
> How do you reproduce the warning?

I am not entirely sure. At first it only happened when disassociating
from the AP at work. The above trace actually appeared when associating
to my home AP.

I have no exact means of reproducing this, it "just happens" during
normal usage, but always during association or disassociation so far.
Sorry that I cannot be more precise.

> Thomas, could you enable lockdep to reproduce and see if any warning
> may be triggered?

Sorry, I don't know what that means.

==============================================================================
TOPIC: viafb: use proper pci config API
http://groups.google.com/group/linux.kernel/t/23b4594cab6fc77b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 12:10 am
From: Harald Welte

Hi Jon + Florian,

On Fri, Apr 09, 2010 at 01:46:10PM -0600, Jonathan Corbet wrote:
> On Thu, 08 Apr 2010 20:42:17 +0200
> Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
>
> > something I am wondering about is whether we can't simply do:
> > viaparinfo->memsize = pci_resource_len(pdev, 0);
> > I suppose that this is not possible meaning that the pci len can be
> > longer than the actual memory but I just wanted to use the moment to
> > make sure.
>
> That would make sense. But if somebody who is closer to the hardware than
> I am doesn't take that approach, I'm nervous about changing it. Harald?

I believe it is not safe to simply use the pci_resource_len(pdev, 0).

At least in some of the hardware I've been working with in the past, the
PCI resource length was always fixed, independent of how large the BIOS
configured the shared video memory.

So please don't use that method.

Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: staging: et131x: et1310_eeprom.c coding style fixes.
http://groups.google.com/group/linux.kernel/t/69accf0878939308?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 12:10 am
From: Lars Lindley

I fixed indentation in one place and two long lines.

Signed-off-by: Lars Lindley <lindley@coyote.org>
---
drivers/staging/et131x/et1310_eeprom.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/et131x/et1310_eeprom.c b/drivers/staging/et131x/et1310_eeprom.c
index e4d095b..5a8e6b9 100644
--- a/drivers/staging/et131x/et1310_eeprom.c
+++ b/drivers/staging/et131x/et1310_eeprom.c
@@ -302,7 +302,7 @@ static int eeprom_read(struct et131x_adapter *etdev, u32 addr, u8 *pdata)
err = eeprom_wait_ready(pdev, NULL);
if (err)
return err;
- /*
+ /*
* Write to the LBCIF Control Register: bit 7=1, bit 6=0, bit 3=0,
* and bits 1:0 both =0. Bit 5 should be set according to the type
* of EEPROM being accessed (1=two byte addressing, 0=one byte
@@ -383,9 +383,9 @@ int et131x_init_eeprom(struct et131x_adapter *etdev)

/* This error could mean that there was an error
* reading the eeprom or that the eeprom doesn't exist.
- * We will treat each case the same and not try to gather
- * additional information that normally would come from the
- * eeprom, like MAC Address
+ * We will treat each case the same and not try to
+ * gather additional information that normally would
+ * come from the eeprom, like MAC Address
*/
etdev->has_eeprom = 0;
return -EIO;
--
1.7.0.4

==============================================================================
TOPIC: viafb: Do not probe for LVDS/TMDS on OLPC XO-1.5
http://groups.google.com/group/linux.kernel/t/89505add244b30dc?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 12:10 am
From: Harald Welte

Hi Florian,

On Fri, Apr 09, 2010 at 11:40:55PM +0200, Florian Tobias Schandinat wrote:

> >The i2c transactions involved in detecting LVDS (9 seconds) and TMDS
> >(16 seconds) add an extra 25 seconds to viafb load time on the XO-1.5.
>
> I don't like the idea of OLPC specific code. Isn't there any way to
> speed this up in general?

I'm quite sure it can be sped up at least a bit... however:

> There is not yet even an option for OLPC_XO_1_5 (in contrast to
> CONFIG_OLPC) in mainline. Is such a thing planned?
> I can't really see anything that would speak for accepting this
> patch now in current mainline, sorry.

I think there is little choice in this matter. It is a _very_ uncommon
hardware design decision to attach anything but the DDC to one of the
I2C ports of the graphics chip, and the assumption that there is only
DDC connected is made in VIA's BIOS (not used in OLPC), the linux
framebuffer driver, as well as VIA's own Xorg driver and I believe as
well in OpenChrome, too :(

OLPC has told me that the particular chip that is attached to I2C is
also very timing sensitive and not 100% I2C compliant, so I think it is
the safe choice to not try to do DDC on that port for the OLPC 1.5.

--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sat, Apr 10 2010 2:00 am
From: Bruno Prémont

On Sat, 10 April 2010 Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> Jonathan Corbet schrieb:
> > On Sat, 10 Apr 2010 01:32:36 +0200
> > Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> >
> >> Please correct me if I am wrong but the remaining 6 patches concerning
> >> suspend&resume look like a real big FIXME. So at the end it is expected
> >> to work only on VX855 and needs something called OFW?
> >
> > OFW = OpenFirmware. You could say BIOS instead. It's pretty normal to
> > expect the BIOS to put things into a semi-rational state at resume time.
>
> So its more or less the same I always do for testing the module.
>
> > Well, if we want to keep s/r out of tree, we can do that. It will
> > complicate the merge of the other stuff, since it's got hooks into the
> > GPIO and camera code too. But, like everything else I've posted so
> > far, it's not the work that I personally set out to do. I can push
> > that work on others :)
> >
> > That said, the suspend/resume support in this patch set makes suspend
> > work on one chipset, and probably comes pretty close on the others
> > without breaking anything there. I don't see the harm in merging it;
> > it makes the code better than it is now. I would rather not have to
> > separate it out from the rest. But I'll not fight over this one; if
> > there's real opposition then we can force OLPC to continue to carry it
> > out of tree.
>
> At least I'd like some more time (multiple weeks) to have a look at this
> issue & patches and try to come up with improvements that make it likely
> work on other IGPs and eventually not needing any BIOS/OFW. I agree its
> already an improvement but certainly one of the kind I like less as VIA
> could come up with such "improvements" too. IMHO it's a bad thing to
> push one chipset first if the target is to support all equally well (as
> long as the hardware permits).
> So I'd be glad if you could go on with the patches that are less painful
> and get them ready for the merge window (as I really don't have a clue
> how long it will take me to get the suspend/resume stuff to a state I
> consider acceptable). Perhaps we should make suspend and resume a
> configure option and mark it as experimental?

In my case (Commell LE 365) the BIOS offers an option to restore graphics
to text mode on resume so the manual call of 'fbset -a $MODE' works
pretty well, only the acceleration has issues.
I don't remember if accel can get revived with vanilla 2.6.34-rc2 if it
was disabled before suspend.

When I get time to, I will give these patches a try. A central GIT tree
where all viafb patches get collected would definitely be nice (even with
multiple semi-throw-away "topic" branches).

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

==============================================================================
TOPIC: staging: et131x: et1310_phy.c coding style fixes.
http://groups.google.com/group/linux.kernel/t/977c019ef0a0a46b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 12:20 am
From: Lars Lindley

I fixed some long lines and whitespace around a =.

Signed-off-by: Lars Lindley <lindley@coyote.org>
---
drivers/staging/et131x/et1310_phy.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/et131x/et1310_phy.c b/drivers/staging/et131x/et1310_phy.c
index 34cd5d1..21c5eee 100644
--- a/drivers/staging/et131x/et1310_phy.c
+++ b/drivers/staging/et131x/et1310_phy.c
@@ -344,7 +344,7 @@ static void ET1310_PhyDuplexMode(struct et131x_adapter *etdev, u16 duplex)
static void ET1310_PhySpeedSelect(struct et131x_adapter *etdev, u16 speed)
{
u16 data;
- static const u16 bits[3]={0x0000, 0x2000, 0x0040};
+ static const u16 bits[3] = {0x0000, 0x2000, 0x0040};

/* Read the PHY control register */
MiRead(etdev, PHY_CONTROL, &data);
@@ -760,7 +760,8 @@ void et131x_Mii_check(struct et131x_adapter *etdev,
if (etdev->linkspeed == TRUEPHY_SPEED_10MBPS) {
/* NOTE - Is there a way to query this without
* TruePHY?
- * && TRU_QueryCoreType(etdev->hTruePhy, 0) == EMI_TRUEPHY_A13O) {
+ * && TRU_QueryCoreType(etdev->hTruePhy, 0) ==
+ * EMI_TRUEPHY_A13O) {
*/
u16 Register18;

@@ -778,7 +779,7 @@ void et131x_Mii_check(struct et131x_adapter *etdev,
* in the LinkDetectionDPC).
*/
if (!(etdev->Flags & fMP_ADAPTER_LINK_DETECTION) ||
- (etdev->MediaState == NETIF_STATUS_MEDIA_DISCONNECT)) {
+ (etdev->MediaState == NETIF_STATUS_MEDIA_DISCONNECT)) {
spin_lock_irqsave(&etdev->Lock, flags);
etdev->MediaState =
NETIF_STATUS_MEDIA_DISCONNECT;
@@ -836,7 +837,8 @@ void et131x_Mii_check(struct et131x_adapter *etdev,
/*
* NOTE - Is there a way to query this without
* TruePHY?
- * && TRU_QueryCoreType(etdev->hTruePhy, 0)== EMI_TRUEPHY_A13O) {
+ * && TRU_QueryCoreType(etdev->hTruePhy, 0)==
+ * EMI_TRUEPHY_A13O) {
*/
u16 Register18;

--
1.7.0.4

==============================================================================
TOPIC: setitimer vs. threads: SIGALRM returned to which thread? (process
master or individual child)
http://groups.google.com/group/linux.kernel/t/0c5f95c047f602a1?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 12:30 am
From: "Frantisek Rysanek"

On 9 Apr 2010 at 23:26, bill o gallmeister wrote:
>
> Check out timer_create() rather than setitimer().
>
Oh I *see* :-) There seems to be a way to deliver an event to a
specific thread. Just a quick guess, haven't validated this by a
compiler:

============ PSEUDOCODE SNIPPET ==========
struct my_thr_data
{
pthread_t ID; /* to be set upon pthread_create() */
/* ...further members... */
};

void* my_fn(void* my_user_data)
{
pthread_kill( ((my_thr_data*)my_user_data)->ID, SIGALRM);
}

struct my_thr_data this_thread;
timer_t my_timer;
struct sigevent my_event =
{
sigev_notify: SIGEV_THREAD,
sigev_notify_function: my_fn,
sigev_value.sival_ptr: &this_thread,
sigev_notify_attributes: NULL
}

timer_create(CLOCK_REALTIME, &my_event, &my_timer);

/* by now we're set up, but the timer doesn't tick yet. */

/* someplace later in the code: */
timer_settime(my_timer, ... );

=========== /PSEUDOCODE SNIPPET ==============
thank you :-)

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

==============================================================================
TOPIC: rmap: make anon_vma_prepare link in all the anon_vmas of a mergeable
VMA
http://groups.google.com/group/linux.kernel/t/eec470a501781823?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 12:30 am
From: Borislav Petkov

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, Apr 09, 2010 at 05:32:36PM -0700

> Exactly. This is the "let's limit things a bit to keep them much simpler.

You gotta love that rule :)

> > Let's hope it fixes Boris's issue.
>
> I'm going to just guess that it won't, and that Boris' issue was actually
> due to something else entirely, and we've all been staring at totally the
> wrong code.
>
> But we can hope.

Now why would you go and jinx it like that... :)

Hibernation runs back-to-back:

1. light system load after boot... ok
2. 3 kvm guests, 3Gb mem free of 8Gb total acc. to /proc/meminfo... ok [ this was the fireproof way to trigger the bug, btw]
3. kvm guests down, firefox loading a 4Mb html page... ok
4. start ubuntu guest, firefox keeps loading the 4Mb html page after previous resume... ok
5. ubuntu guest booting done, firefox done, play video... ok
6. video broken after resume due to:

[AO_ALSA] Pcm in suspend mode, trying to resume. 212% 2% 1.7% 1 0
[AO_ALSA] alsa-lib: pcm_hw.c:709:(snd_pcm_hw_resume) SNDRV_PCM_IOCTL_RESUME failed: Function not implemented

i.e., unrelated... still ok

7. ubuntu guest downloading a 100Mb file causing allocation of a bunch of anon memory in the host... ok
8. all guests off, firefox off, back to light load... ok

No oopsies or problems in dmesg except the old lockdep sysfs warning.

I will keep running that kernel in the next couple of days and keep you
informed in case this is the fix we're gonna use.

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

==============================================================================
TOPIC: Kernel crash in xfs_iflush_cluster (was Somebody take a look please!...)

http://groups.google.com/group/linux.kernel/t/31111d6646356936?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 1:10 am
From: Américo Wang

On Sat, Apr 10, 2010 at 12:44:28AM +0200, Janos Haar wrote:
> Hello,
>

Hi,

> I am just started to test the stable-queue patch series on 2.6.32.10.
> Now running, we will see...
> The 2.6.33.2 made 4 crashes in the last 3 days. :-(
> This was more worse than the original 2.6.32.10.
>
> (I am very interested, anyway, this is the last shot of this server.
> The owner giving me an ultimate.
> If the server crashes again in the next week, i need to replace the
> entire HW, the OS, and the services as well...)
>

I would recommend you to use a distribution-released kernel,
rather than a stable kernel from kernel.org, because usually
the distribution maintains a longer supported kernel than
kernel.org.

Just a little suggestion. Hope it helps for you to choose Linux. ;)

Thanks.

--
Live like a child, think like the god.

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

==============================================================================
TOPIC: rcu: add rcu_access_pointer and rcu_dereference_protected
http://groups.google.com/group/linux.kernel/t/21441064d06b7f4d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 1:20 am
From: David Howells

Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> This patch adds variants of rcu_dereference() that handle situations
> where the RCU-protected data structure cannot change, perhaps due to
> our holding the update-side lock, or where the RCU-protected pointer is
> only to be fetched, not dereferenced. These are needed due to some
> performance concerns with using rcu_dereference() where it is not
> required, aside from the need for lockdep/sparse checking.
>
> The new rcu_access_pointer() primitive is for the case where the pointer
> is be fetch and not dereferenced. This primitive may be used without
> protection, RCU or otherwise, due to the fact that it uses ACCESS_ONCE().
>
> The new rcu_dereference_protected() primitive is for the case where updates
> are prevented, for example, due to holding the update-side lock. This
> primitive does neither ACCESS_ONCE() nor smp_read_barrier_depends(), so
> can only be used when updates are somehow prevented.
>
> Suggested-by: David Howells <dhowells@redhat.com>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

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

==============================================================================
TOPIC: proc: make task_sig() lockless
http://groups.google.com/group/linux.kernel/t/5598dbf16865e26b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 1:20 am
From: David Howells

Roland McGrath <roland@redhat.com> wrote:

> I'm not so sure. Operations like sigprocmask and sigaction really have
> always been entirely atomic from the userland perspective before. Now it
> becomes possible to read from /proc e.g. a blocked set that never existed
> as such (one word updated by sigprocmask but not yet the next word).

If you have a small userspace buffer, that was previously possible too.

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

==============================================================================
TOPIC: USB transfer_buffer allocations on 64bit systems
http://groups.google.com/group/linux.kernel/t/a96a33ce18e828e9?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 1:40 am
From: Daniel Mack

On Fri, Apr 09, 2010 at 05:38:13PM -0600, Robert Hancock wrote:
> On Fri, Apr 9, 2010 at 10:50 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> > What makes you think that? I've seen URB buffers with 64-bit DMA
> > addresses. I can tell when the debug polling loop runs and I look at
> > the DMA addresses the xHCI driver is feeding to the hardware:
> >
> > Dev 1 endpoint ring 0:
> > xhci_hcd 0000:05:00.0: @71a49800 01000680 00080000 00000008 00000841
> >
> > So the TRB at address 71a49800 is pointing to a buffer at address
> > 0x0008000001000680.
>
> I'm not sure why the address would be that huge, unless it's not
> actually a physical address, or there's some kind of remapping going
> on?
>
> >
> > If I'm setting a DMA mask wrong somewhere, or doing something else to
> > limit the DMA to 32-bit, then please let me know.
>
> The DMA mask for the controller isn't being set anywhere (in the
> version that's in Linus' current git anyway). In that case it'll
> default to 32-bit and any DMA mappings above 4GB will need to be
> remapped. The controller driver doesn't do the mapping itself but the
> USB core does, passing in the controller device as the one doing the
> DMA, so if the controller's DMA mask is set to 32-bit then the buffers
> passed in will get remapped/bounced accordingly.

So if we're seeing physical addresses in the log above, and the xHCI
driver does not explicitly allow the USB core to use addresses above
4GB, why shouldn't the same thing be true as well for EHCI?
(Which would then be exactly the case we're seeing)

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

== 2 of 2 ==
Date: Sat, Apr 10 2010 5:50 am
From: Daniel Mack

On Fri, Apr 09, 2010 at 07:19:22PM +0100, Pedro Ribeiro wrote:
> On 9 April 2010 19:09, Daniel Mack <daniel@caiaq.de> wrote:
> > On Fri, Apr 09, 2010 at 12:01:27PM -0400, Alan Stern wrote:
> >> I don't see anything suspicious. The transfer_buffer addresses repeat
> >> every 32 URBs, and the DMA addresses cycle almost entirely uniformly
> >> from 0x20000000 to 0x23ffffff in units of 0x2000 (there are a few gaps
> >> where the interval is a little bigger).
> >
> > The DMA pointers do indeed look sane. I wanted to take a deeper look at
> > this and set up a 64bit system today. However, I fail to see the problem
> > here. Pedro, how much RAM does your machine have installed?
> >
> > Daniel
> >
> >
>
> It has 4 GB.

Upgraded my machine now to 4GB, but I still can't reproduce this bug.
Pedro, can you send your config, please?

==============================================================================
TOPIC: 2.6.34-rc3 doesn't suspend to disk (-rc2 did)
http://groups.google.com/group/linux.kernel/t/88d031f36fa07259?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 1:50 am
From: Jiri Slaby

On 04/08/2010 08:44 PM, Maciej Rutecki wrote:
> On piątek, 2 kwietnia 2010 o 02:19:26 Jiri Kosina wrote:
>> Hi,
>>
>> I have just hit this problem. Haven't bisected it yet, and going through
>> shortlog doesn't ring any bell immediately, so I am sending this out in
>> case it rings a bell for someone right away.
>
> I created a Bugzilla entry at
> https://bugzilla.kernel.org/show_bug.cgi?id=15728

Jiri, could you add there whether you changed config options somehow?
The bug drives me crazy.

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

== 2 of 2 ==
Date: Sat, Apr 10 2010 1:50 am
From: Jiri Slaby

On 04/10/2010 10:42 AM, Jiri Slaby wrote:
> Jiri, could you add there whether you changed config options somehow?
> The bug drives me crazy.

(and check whether the fix there solves your problem or we hit different
issues)

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

==============================================================================
TOPIC: Probing System calls
http://groups.google.com/group/linux.kernel/t/01e4b7f90a084e6b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 1:50 am
From: Siddhartha Chhabra

I am trying to probe the read and write system calls using jprobe and
kretprobes. In the first place, sys_read was not exported, so I have
exported the symbol and I am successfully able to register the probes.
Next I have a small piece of code that just invokes the read system
call. Now after I insert the module with the probes and run the
program with the read system call, it does not show the system call
called with the size parameter that I pass. For e.g. I call ./read
1234, the debug messages have a lot of prints but for sizes like 1,
4096, but never 1234. Since the debug message are getting printed, it
tells me that the probe has been registered successfully, however, I
was wondering why it never gives a message with the size i passed. Is
there something I am missing on probing the system call, or is there a
fundamental limitation on probing system calls...

I appreciate any comments/suggestion...

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

==============================================================================
TOPIC: 2.6.31 regression: programs crashing after a couple of days of uptime
with hibernation
http://groups.google.com/group/linux.kernel/t/c57662f68a76c20d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 2:10 am
From: Ondrej Zary

On Friday 02 April 2010 18:58:28 Rafael J. Wysocki wrote:
> On Friday 02 April 2010, Ondrej Zary wrote:
> > On Friday 02 April 2010 00:33:55 Rafael J. Wysocki wrote:
> > > On Friday 02 April 2010, Ondrej Zary wrote:
> > > > On Thursday 01 April 2010 23:45:33 you wrote:
> > > > > On Thursday 01 April 2010, Ondrej Zary wrote:
> > > > > > Hello,
> > > > > > with kernel 2.6.30, I can have uptime of more than a month on my
> > > > > > desktop PC (with hibernation). It's impossible with 2.6.31. After
> > > > > > 1 to 3 days, processes that were running during hibernation (e.g.
> > > > > > konsole, kwin, kicker, xorg) start to crash randomly in very
> > > > > > weird ways. The kernel itself does not seem to crash. When I run
> > > > > > the crashed program again, it seems to work. Looks like some
> > > > > > memory corruption.
> > > > > >
> > > > > > This bug is also present in 2.6.32 and 2.6.33.
> > > > >
> > > > > Is the kernel 32-bit or 64-bit? What kind of CPU is there in the
> > > > > box?
> > > >
> > > > It's old 32-bit i686 CPU - Cyrix MII.
> > >
> > > Please try with this patch applied:
> > > http://git.kernel.org/?p=linux/kernel/git/mingo/linux-2.6-x86.git;a=pat
> > >ch;h =8ae06d223f8203c72104e5c0c4ee49a000aedb42
> >
> > Thanks, I'll try it. But I doubt that it will fix the problem. There were
> > no changes in hibernate_asm_32.S between 2.6.30 and 2.6.31.
>
> The change that exposed this issue was elsewhere in the x86 arch code. I
> don't know where exactly, but we surely didn't need the above patch before.

It did not help. It started crashing with 2.6.32 and this patch applied after
two days.

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

==============================================================================
TOPIC: MTD: Suppress warnings in inline_map_read()
http://groups.google.com/group/linux.kernel/t/9f6eabab93c6a5e5?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 2:30 am
From: David Woodhouse

On Fri, 2010-04-09 at 15:45 -0700, Kevin Cernekee wrote:
> With gcc 4.4.3 -O2 on MIPS32:
>
> drivers/mtd/chips/cfi_util.c: In function 'cfi_qry_present':
> include/linux/mtd/map.h:390: warning: 'r' may be used uninitialized in this function
> include/linux/mtd/map.h:375: note: 'r' was declared here
> include/linux/mtd/map.h:390: warning: 'r' may be used uninitialized in this function
> include/linux/mtd/map.h:375: note: 'r' was declared here
>
> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>

I suspect 'else BUG()' would be a better fix.

--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation

==============================================================================
TOPIC: Linux 2.6.34-rc3 + CAN build problem
http://groups.google.com/group/linux.kernel/t/4a588016aca1bbac?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Apr 10 2010 2:50 am
From: Eric Dumazet

Le samedi 10 avril 2010 à 10:13 +0200, Németh Márton a écrit :
> Hi,
>
> I have some problem building Liunux kernel 2.6.34-rc3 with the attached .config:
>
> $ make clean bzImage modules
> [...]
> CC net/socket.o
> LD net/802/built-in.o
> LD net/can/built-in.o
> CC [M] net/can/bcm.o
> CC [M] net/can/raw.o
> In file included from /mnt/store/nmarci/src/linux-2.6.34-rc3/arch/x86/include/asm/uaccess.h:571,
> from include/net/checksum.h:25,
> from include/linux/skbuff.h:28,
> from include/linux/if_ether.h:124,
> from include/linux/netdevice.h:29,
> from net/can/raw.c:48:
> In function 'copy_from_user',
> inlined from 'raw_setsockopt' at net/can/raw.c:447:
> /mnt/store/nmarci/src/linux-2.6.34-rc3/arch/x86/include/asm/uaccess_32.h:212: error: call to 'copy_from_user_overflow' declared with attribute error:
> copy_from_user() buffer size is not provably correct
> make[2]: *** [net/can/raw.o] Error 1
> make[1]: *** [net/can] Error 2
> make: *** [net] Error 2
>
>

Could you give us your compiler version ?

Code is fine, but compiler a bit dumb :(

[PATCH] can: avoids a false warning

At this point optlen == sizeof(sfilter) but some compilers are dumb.

Reported-by: Németh Márton <nm127@freemail.h
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/can/raw.c b/net/can/raw.c
index 3a7dffb..da99cf1 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -445,7 +445,7 @@ static int raw_setsockopt(struct socket *sock, int level, int optname,
return -EFAULT;
}
} else if (count == 1) {
- if (copy_from_user(&sfilter, optval, optlen))
+ if (copy_from_user(&sfilter, optval, sizeof(sfilter)))
return -EFAULT;
}

== 2 of 3 ==
Date: Sat, Apr 10 2010 3:40 am
From: Németh Márton

Eric Dumazet írta:
> Le samedi 10 avril 2010 à 10:13 +0200, Németh Márton a écrit :
>> Hi,
>>
>> I have some problem building Liunux kernel 2.6.34-rc3 with the attached .config:
>>
>> $ make clean bzImage modules
>> [...]
>> CC net/socket.o
>> LD net/802/built-in.o
>> LD net/can/built-in.o
>> CC [M] net/can/bcm.o
>> CC [M] net/can/raw.o
>> In file included from /mnt/store/nmarci/src/linux-2.6.34-rc3/arch/x86/include/asm/uaccess.h:571,
>> from include/net/checksum.h:25,
>> from include/linux/skbuff.h:28,
>> from include/linux/if_ether.h:124,
>> from include/linux/netdevice.h:29,
>> from net/can/raw.c:48:
>> In function 'copy_from_user',
>> inlined from 'raw_setsockopt' at net/can/raw.c:447:
>> /mnt/store/nmarci/src/linux-2.6.34-rc3/arch/x86/include/asm/uaccess_32.h:212: error: call to 'copy_from_user_overflow' declared with attribute error:
>> copy_from_user() buffer size is not provably correct
>> make[2]: *** [net/can/raw.o] Error 1
>> make[1]: *** [net/can] Error 2
>> make: *** [net] Error 2
>>
>>
>
> Could you give us your compiler version ?

$ gcc --version
gcc (Debian 4.4.2-9) 4.4.3 20100108 (prerelease)
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> Code is fine, but compiler a bit dumb :(
>
> [PATCH] can: avoids a false warning
>
> At this point optlen == sizeof(sfilter) but some compilers are dumb.
>
> Reported-by: Németh Márton <nm127@freemail.h
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> diff --git a/net/can/raw.c b/net/can/raw.c
> index 3a7dffb..da99cf1 100644
> --- a/net/can/raw.c
> +++ b/net/can/raw.c
> @@ -445,7 +445,7 @@ static int raw_setsockopt(struct socket *sock, int level, int optname,
> return -EFAULT;
> }
> } else if (count == 1) {
> - if (copy_from_user(&sfilter, optval, optlen))
> + if (copy_from_user(&sfilter, optval, sizeof(sfilter)))
> return -EFAULT;
> }
>
>
>
>
>

== 3 of 3 ==
Date: Sat, Apr 10 2010 5:40 am
From: Oliver Hartkopp

Németh Márton wrote:
> Eric Dumazet írta:
>> Le samedi 10 avril 2010 à 10:13 +0200, Németh Márton a écrit :
>>> Hi,
>>>
>>> I have some problem building Liunux kernel 2.6.34-rc3 with the attached .config:
>>>
>>> $ make clean bzImage modules
>>> [...]
>>> CC net/socket.o
>>> LD net/802/built-in.o
>>> LD net/can/built-in.o
>>> CC [M] net/can/bcm.o
>>> CC [M] net/can/raw.o
>>> In file included from /mnt/store/nmarci/src/linux-2.6.34-rc3/arch/x86/include/asm/uaccess.h:571,
>>> from include/net/checksum.h:25,
>>> from include/linux/skbuff.h:28,
>>> from include/linux/if_ether.h:124,
>>> from include/linux/netdevice.h:29,
>>> from net/can/raw.c:48:
>>> In function 'copy_from_user',
>>> inlined from 'raw_setsockopt' at net/can/raw.c:447:
>>> /mnt/store/nmarci/src/linux-2.6.34-rc3/arch/x86/include/asm/uaccess_32.h:212: error: call to 'copy_from_user_overflow' declared with attribute error:
>>> copy_from_user() buffer size is not provably correct
>>> make[2]: *** [net/can/raw.o] Error 1
>>> make[1]: *** [net/can] Error 2
>>> make: *** [net] Error 2
>>>
>>>
>> Could you give us your compiler version ?
>
> $ gcc --version
> gcc (Debian 4.4.2-9) 4.4.3 20100108 (prerelease)
> Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>> Code is fine, but compiler a bit dumb :(
>>
>> [PATCH] can: avoids a false warning
>>
>> At this point optlen == sizeof(sfilter) but some compilers are dumb.
>>
>> Reported-by: Németh Márton <nm127@freemail.h
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Acked-by: Oliver Hartkopp <oliver@hartkopp.net>

Btw. i'm using the same compiler here (Debian Squeeze), and i did not have any
build problems with 2.6.24-rc3 and the following kernels like the currently
running 2.6.34-rc3-00288-gab195c5:

$ cat /proc/version
Linux version 2.6.34-rc3-00288-gab195c5 (hartko@vwagwolkf320) (gcc version
4.4.3 20100108 (prerelease) (Debian 4.4.2-9) ) #70 SMP Tue Apr 6 19:14:52 CEST
2010

So i wonder why Nemeth trapped into this problem ... probably an include file
mix-up?

Regards,
Oliver

>> ---
>> diff --git a/net/can/raw.c b/net/can/raw.c
>> index 3a7dffb..da99cf1 100644
>> --- a/net/can/raw.c
>> +++ b/net/can/raw.c
>> @@ -445,7 +445,7 @@ static int raw_setsockopt(struct socket *sock, int level, int optname,
>> return -EFAULT;
>> }
>> } else if (count == 1) {
>> - if (copy_from_user(&sfilter, optval, optlen))
>> + if (copy_from_user(&sfilter, optval, sizeof(sfilter)))
>> return -EFAULT;
>> }
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Add "nested" field to event of lock_release
http://groups.google.com/group/linux.kernel/t/241df274c77cdce0?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 3:50 am
From: Hitoshi Mitake

State machine of perf lock requires "nested" field of lock_release(),
so this patch adds it to event.

Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>

---
include/trace/events/lock.h | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/lock.h b/include/trace/events/lock.h
index 5c1dcfc..4f489b5 100644
--- a/include/trace/events/lock.h
+++ b/include/trace/events/lock.h
@@ -44,15 +44,17 @@ TRACE_EVENT(lock_release,
TP_STRUCT__entry(
__string(name, lock->name)
__field(void *, lockdep_addr)
+ __field(int, nested)
),

TP_fast_assign(
__assign_str(name, lock->name);
__entry->lockdep_addr = lock;
+ __entry->nested = nested;
),

- TP_printk("%p %s",
- __entry->lockdep_addr, __get_str(name))
+ TP_printk("%p %s %d",
+ __entry->lockdep_addr, __get_str(name), __entry->nested)
);

#ifdef CONFIG_LOCK_STAT
--
1.6.5.2

==============================================================================
TOPIC: Question about lock sequence
http://groups.google.com/group/linux.kernel/t/96b38e24ca76f796?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 3:50 am
From: Hitoshi Mitake

Hi,

I found that my understand about lockdep is completely wrong :( ,
so state machine of perf lock should be fixed before optimization.

And I found that behaviour related to some of spin locks are strange.
The concrete example is lock sequences targeting dcache_lock (defined in
head of fs/dcache.c).

I made a little (and not essential) change to perf lock, and observe
lock sequence targeting it.
Changed perf lock shows sequence of locks in time order,
and I grepped the output of it with dcache, like this:

% sudo ./perf lock report | grep dcache

The head part of result is this:
# <name>-<pid> <time (in u64)> <action> <address of lockdep> <name of lock>
perf-3238 92430534170 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92430536714 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92431444481 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92431446061 acquired: 0xffffffff81a4b398 dcache_lock
perf-3238 92431448157 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92431449670 acquired: 0xffffffff81a4b398 dcache_lock
perf-3238 92432371136 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92432372712 acquired: 0xffffffff81a4b398 dcache_lock
perf-3238 92432374718 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92432376173 acquired: 0xffffffff81a4b398 dcache_lock
perf-3238 92433315563 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92433317173 acquired: 0xffffffff81a4b398 dcache_lock

There are too many acquire and acquired without corresponding release
(or contended).
If dcache_lock is rwlock and these acquires mean read locks, this is not
so strange.
But, for me, this is a pattern of dead lock.
Of course perf lock finished its work, so there is no actual dead lock.

If you know something about this behaviour of lock, could you tell me?

Thanks,
Hitoshi

==============================================================================
TOPIC: tcp: add setsockopt to disable slow start after idle
http://groups.google.com/group/linux.kernel/t/7e8dc919f86384a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 5:10 am
From: Cristian KLEIN

On 10/04/2010 07:13, David Miller wrote:
> From: Cristian KLEIN<cristiklein@gmail.com>
> Date: Sat, 10 Apr 2010 03:30:15 +0200
>
>> Allows user-space to override the sysctl
>> net.ipv4.tcp_slow_start_after_idle, on a per-socket bases, using
>> setsockopt().
>>
>> Slow start after idle can harm some scientific applications which
>> interleave computation and communication. Assume we have an iterative
>> applications, each iteration consisting of a computation and a
>> communication phase. If the computation phase takes long enough (i.e.
>> more that 2*RTT), the communication phase will always slow start and
>> might never reach the wire speed.
>>
>> This patch allows each application to disable slow start after idle,
>> just like we allow delay-sensitive applications (e.g. telnet, SSH) to
>> disable NAGLE.
>>
>> Signed-off-by: Cristian KLEIN<cristiklein@gmail.com>
>
> We specifically did not add a socket option for this facility.
>
> It is a very dangerous option to enable, and depends deeply
> upon the characteristics of your network and the paths by
> which remote hosts are reached.
>
> Therefore, only the system administrator can determine whether it is
> safe to enable this, and that's why it can only be changed via sysctl.
> Lettting arbitrary applications change this aspect of TCP is beyond
> dangerous.
>
> I will not be applying this patch.

Could you please explain me why it is dangerous? To me it seems that
it's just like allowing applications to disable NAGLE or to choose a
congestion control algorithm.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Saturday, April 10, 2010

linux.kernel - 25 new messages in 19 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts