summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2010-01-18Linux 2.6.32.4v2.6.32.4Greg Kroah-Hartman
2010-01-18agp/intel-agp: Clear entire GTT on startupDavid Woodhouse
commit fc61901373987ad61851ed001fe971f3ee8d96a3 upstream. Some BIOSes fail to initialise the GTT, which will cause DMA faults when the IOMMU is enabled. We need to clear the whole thing to point at the scratch page, not just the part that Linux is going to use. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> [anholt: Note that this may also help with stability in the presence of driver bugs, by not drawing to memory we don't own] Signed-off-by: Eric Anholt <eric@anholt.net> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18ipv6: skb_dst() can be NULL in ipv6_hop_jumbo().David S. Miller
commit 2570a4f5428bcdb1077622342181755741e7fa60 upstream. This fixes CERT-FI FICORA #341748 Discovered by Olli Jarva and Tuomo Untinen from the CROSS project at Codenomicon Ltd. Just like in CVE-2007-4567, we can't rely upon skb_dst() being non-NULL at this point. We fixed that in commit e76b2b2567b83448c2ee85a896433b96150c92e6 ("[IPV6]: Do no rely on skb->dst before it is assigned.") However commit 483a47d2fe794328d29950fe00ce26dd405d9437 ("ipv6: added net argument to IP6_INC_STATS_BH") put a new version of the same bug into this function. Complicating analysis further, this bug can only trigger when network namespaces are enabled in the build. When namespaces are turned off, the dev_net() does not evaluate it's argument, so the dereference would not occur. So, for a long time, namespaces couldn't be turned on unless SYSFS was disabled. Therefore, this code has largely been disabled except by people turning it on explicitly for namespace development. With help from Eugene Teo <eugene@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=yRusty Russell
commit d4703aefdbc8f9f347f6dcefcddd791294314eb7 upstream. powerpc applies relocations to the kcrctab. They're absolute symbols, but it's not completely unreasonable: other archs may too, but the relocation is often 0. http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-November/077972.html Inspired-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Tested-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18fix more leaks in audit_tree.c tag_chunk()Al Viro
commit b4c30aad39805902cf5b855aa8a8b22d728ad057 upstream. Several leaks in audit_tree didn't get caught by commit 318b6d3d7ddbcad3d6867e630711b8a705d873d7, including the leak on normal exit in case of multiple rules refering to the same chunk. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18fix braindamage in audit_tree.c untag_chunk()Al Viro
commit 6f5d51148921c242680a7a1d9913384a30ab3cbe upstream. ... aka "Al had badly fscked up when writing that thing and nobody noticed until Eric had fixed leaks that used to mask the breakage". The function essentially creates a copy of old array sans one element and replaces the references to elements of original (they are on cyclic lists) with those to corresponding elements of new one. After that the old one is fair game for freeing. First of all, there's a dumb braino: when we get to list_replace_init we use indices for wrong arrays - position in new one with the old array and vice versa. Another bug is more subtle - termination condition is wrong if the element to be excluded happens to be the last one. We shouldn't go until we fill the new array, we should go until we'd finished the old one. Otherwise the element we are trying to kill will remain on the cyclic lists... That crap used to be masked by several leaks, so it was not quite trivial to hit. Eric had fixed some of those leaks a while ago and the shit had hit the fan... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18mac80211: fix skb buffering issue (and fixes to that)Johannes Berg
This is a backport of the mainline patches cf0277e714a0db302a8f80e1b85fd61c32cf00b3 045cfb71a3901005bf6dcedae98cecb3360a0bfc b49bb574e44226b332c28439999d196ddec2f643 Here is the description of the first of those patches (the other two just fixed bugs added by that patch): Since I removed the master netdev, we've been keeping internal queues only, and even before that we never told the networking stack above the virtual interfaces about congestion. This means that packets are queued in mac80211 and the upper layers never know, possibly leading to memory exhaustion and other problems. This patch makes all interfaces multiqueue and uses ndo_select_queue to put the packets into queues per AC. Additionally, when the driver stops a queue, we now stop all corresponding queues for the virtual interfaces as well. The injection case will use VO by default for non-data frames, and BE for data frames, but downgrade any data frames according to ACM. It needs to be fleshed out in the future to allow chosing the queue/AC in radiotap. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Cc: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18kernel/sysctl.c: fix stable merge error in NOMMU mmap_min_addrMike Frysinger
Stable commit 0399123f3dcce1a515d021107ec0fb4413ca3efa didn't match the original upstream commit. The CONFIG_MMU check was added much too early in the list disabling a lot of proc entries in the process. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18libertas: Remove carrier signaling from the scan codeSamuel Ortiz
commit 659c8e5243caf14564155ad8421404f044dd8031 upstream. There is no reason to signal a carrier off when doing a 802.11 scan. Cc: Holger Schurig <holgerschurig@gmail.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm/i915: remove render reclock supportJesse Barnes
commit cda9d05c499093c67b4a376a15009923acc2127a upstream. This code generally fails to adjust the render clock, and when it does, it conflicts with some other register settings and can cause problems. So remove this code altogether. I'm reworking it now to do the right thing, but the only bit it will share is the VBT check for whether reclocking is supported, so I'm leaving that bit. Reverts most of 652c393a3368af84359da37c45afc35a91144960 ("add dynamic clock frequency control"), though for many the regressions showed up in the later 181a5336d6cc836f05507410d66988c483ad0154 ("Fix render reclock availability detection"). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18mac80211: add missing sanity checks for action framesFelix Fietkau
commit d79074488083ec0d7ecd15352192dc1631f25643 upstream. Various missing sanity checks caused rejected action frames to be interpreted as channel switch announcements, which can cause a client mode interface to switch away from its operating channel, thereby losing connectivity. This patch ensures that only spectrum management action frames are processed by the CSA handling function and prevents rejected action frames from getting processed by the MLME code. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18iwl: off by one bugDan Carpenter
commit 8a9ac160e844c7ce8074f6aa531feefb4acdee7c upstream. tid is used as an array offset. agg = &priv->stations[sta_id].tid[tid].agg; iwl4965_tx_status_reply_tx(priv, agg, tx_resp, txq_id, index); It should be limitted to MAX_TID_COUNT - 1; struct iwl_tid_data tid[MAX_TID_COUNT]; regards, dan carpenter Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18cfg80211: fix syntax error on user regulatory hintsLuis R. Rodriguez
commit e12822e1d3fface0d9e1095c5177e10141bd6bd6 upstream. This fixes a syntax error when setting up the user regulatory hint. This change yields the same exact binary object though so it ends up just being a syntax typo fix, fortunately. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18ath5k: Fix eeprom checksum check for custom sized eepromsLuis R. Rodriguez
commit 359207c687cc8f4f9845c8dadd0d6dabad44e584 upstream. Commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 enabled EEPROM checksum checks to avoid bogus bug reports but failed to address updating the code to consider devices with custom EEPROM sizes. Devices with custom sized EEPROMs have the upper limit size stuffed in the EEPROM. Use this as the upper limit instead of the static default size. In case of a checksum error also provide back the max size and whether or not this was the default size or a custom one. If the EEPROM is busted we add a failsafe check to ensure we don't loop forever or try to read bogus areas of hardware. This closes bug 14874 http://bugzilla.kernel.org/show_bug.cgi?id=14874 Cc: David Quan <david.quan@atheros.com> Cc: Stephen Beahm <stephenbeahm@comcast.net> Reported-by: Joshua Covington <joshuacov@googlemail.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18iwlwifi: fix iwl_queue_used bug when read_ptr == write_ptrZhu Yi
commit c8106d7625a58ee4387cb2efe3e82320ad44b467 upstream. When txq read_ptr equals to write_ptr, iwl_queue_used should always return false. Because there is no used TFD in this case. This is a complementary fix to the fix already included in commit "iwl3945: fix panic in iwl3945 driver". Both fixes are needed to address the panic below. This problem was discussed on linux-wireless in http://thread.gmane.org/gmane.linux.kernel.wireless.general/43568 <1>[ 7290.414172] IP: [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.414205] PGD 0 <1>[ 7290.414214] Thread overran stack, or stack corrupted <0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP <0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input <4>[ 7290.414265] CPU 0 <4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress <6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P 2.6.32-rc8-wl #213 Aspire 5720 <6>[ 7290.414507] RIP: 0010:[<ffffffffa0dd53a1>] [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <6>[ 7290.414541] RSP: 0018:ffff880002203d60 EFLAGS: 00010246 <6>[ 7290.414557] RAX: 000000000000004f RBX: ffff880064c11600 RCX: 0000000000000013 <6>[ 7290.414576] RDX: ffffffffa0ddcf20 RSI: ffff8800512b7008 RDI: 0000000000000038 <6>[ 7290.414596] RBP: ffff880002203dd0 R08: 0000000000000000 R09: 0000000000000100 <6>[ 7290.414616] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000a0 <6>[ 7290.414635] R13: 0000000000000002 R14: 0000000000000013 R15: 0000000000020201 <6>[ 7290.414655] FS: 0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000 <6>[ 7290.414677] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b <6>[ 7290.414693] CR2: 0000000000000041 CR3: 0000000001001000 CR4: 00000000000006f0 <6>[ 7290.414712] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <6>[ 7290.414732] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 <4>[ 7290.414752] Process swapper (pid: 0, threadinfo ffffffff81524000, task ffffffff81528b60) <0>[ 7290.414772] Stack: <4>[ 7290.414780] ffff880002203da0 0000000000000046 0000000000000000 0000000000000046 <4>[ 7290.414804] <0> 0000000000000282 0000000000000282 0000000000000282 ffff880064c12010 <4>[ 7290.414830] <0> ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000 <0>[ 7290.414858] Call Trace: <0>[ 7290.414867] <IRQ> <4>[ 7290.414884] [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945] <4>[ 7290.414910] [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60 <4>[ 7290.414931] [<ffffffff81049a21>] tasklet_action+0x101/0x110 <4>[ 7290.414950] [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160 <4>[ 7290.414968] [<ffffffff8100d01c>] call_softirq+0x1c/0x30 <4>[ 7290.414986] [<ffffffff8100eff5>] do_softirq+0x75/0xb0 <4>[ 7290.415003] [<ffffffff81049ee5>] irq_exit+0x95/0xa0 <4>[ 7290.415020] [<ffffffff8100e547>] do_IRQ+0x77/0xf0 <4>[ 7290.415038] [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf <0>[ 7290.415052] <EOI> <4>[ 7290.415067] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415087] [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5 <4>[ 7290.415107] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415130] [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0 <4>[ 7290.415149] [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110 <4>[ 7290.415168] [<ffffffff8137b3d5>] ? rest_init+0x75/0x80 <4>[ 7290.415187] [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3 <4>[ 7290.415206] [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129 <4>[ 7290.415227] [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb <0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49 <1>[ 7290.415382] RIP [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.415410] RSP <ffff880002203d60> <0>[ 7290.415421] CR2: 0000000000000041 <4>[ 7290.415436] ---[ end trace ec46807277caa515 ]--- <0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt <4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P D 2.6.32-rc8-wl #213 <4>[ 7290.415486] Call Trace: <4>[ 7290.415495] <IRQ> [<ffffffff8138c040>] panic+0x7d/0x13a <4>[ 7290.415519] [<ffffffff8101071a>] oops_end+0xda/0xe0 <4>[ 7290.415538] [<ffffffff8102e1ea>] no_context+0xea/0x250 <4>[ 7290.415557] [<ffffffff81038991>] ? select_task_rq_fair+0x511/0x780 <4>[ 7290.415578] [<ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0 <4>[ 7290.415597] [<ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80 <4>[ 7290.415616] [<ffffffff81039201>] ? enqueue_task_fair+0x111/0x150 <4>[ 7290.415636] [<ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10 <4>[ 7290.415656] [<ffffffff8102e8fa>] do_page_fault+0x26a/0x320 <4>[ 7290.415674] [<ffffffff813905df>] page_fault+0x1f/0x30 <4>[ 7290.415697] [<ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.415723] [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945] <4>[ 7290.415746] [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60 <4>[ 7290.415764] [<ffffffff81049a21>] tasklet_action+0x101/0x110 <4>[ 7290.415783] [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160 <4>[ 7290.415801] [<ffffffff8100d01c>] call_softirq+0x1c/0x30 <4>[ 7290.415818] [<ffffffff8100eff5>] do_softirq+0x75/0xb0 <4>[ 7290.415835] [<ffffffff81049ee5>] irq_exit+0x95/0xa0 <4>[ 7290.415852] [<ffffffff8100e547>] do_IRQ+0x77/0xf0 <4>[ 7290.415869] [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf <4>[ 7290.415883] <EOI> [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415911] [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5 <4>[ 7290.415931] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415952] [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0 <4>[ 7290.415971] [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110 <4>[ 7290.415989] [<ffffffff8137b3d5>] ? rest_init+0x75/0x80 <4>[ 7290.416007] [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3 <4>[ 7290.416026] [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129 <4>[ 7290.416047] [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb Reported-by: Maxim Levitsky <maximlevitsky@gmail.com> Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18xen: fix hang on suspend.Ian Campbell
commit c5cae661d6cf808b6984762f763261adf35f3eb7 upstream. In 65f63384 "xen: improve error handling in do_suspend" I said: - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not nested in the obvious way. and changed the ordering of the calls as so: BEFORE AFTER xs_suspend dpm_suspend_noirq dpm_suspend_noirq xs_suspend *SUSPEND* *SUSPEND* dpm_resume_noirq dpm_resume_noirq xs_resume xs_resume Clearly this is not an improvement and I was talking rubbish. In particular the new ordering is susceptible to a hang if a xenstore write is in progress at the point at which the suspend kicks in. When the suspend process calls xs_suspend it tries to take the request_mutex but if a write is in progress it could be looping in xenbus_xs.c:read_reply() waiting for something to arrive on &xs_state.reply_list while holding the request_mutex (taken in the caller of read_reply). However if we have done dpm_suspend_noirq before xs_suspend then we won't get any more xenstore interrupts and process_msg() will never be woken up to add anything to the reply_list. Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq fails then make sure we go through the xs_suspend_cancel() code path. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18quota: Fix dquot_transfer for filesystems different from ext4Jan Kara
commit 05b5d898235401c489c68e1f3bc5706a29ad5713 upstream. Commit fd8fbfc1 modified the way we find amount of reserved space belonging to an inode. The amount of reserved space is checked from dquot_transfer and thus inode_reserved_space gets called even for filesystems that don't provide get_reserved_space callback which results in a BUG. Fix the problem by checking get_reserved_space callback and return 0 if the filesystem does not provide it. CC: Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18hwmon: (adt7462) Fix pin 28 monitoringRoger Blofeld
commit bb595c923bc51dff9cdd112de18deb57ac7945d2 upstream. The ADT7462_PIN28_VOLT value is a 4-bit field, so the corresponding shift must be 4. Signed-off-by: Roger Blofeld <blofeldus@yahoo.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18hwmon: (coretemp) Fix TjMax for Atom N450/D410/D510 CPUsYong Wang
commit 1fe63ab47a617ee95f562eaa7ddbbc59981ff8c6 upstream. The max junction temperature of Atom N450/D410/D510 CPUs is 100 degrees Celsius. Since these CPUs are always coupled with Intel NM10 chipset in one package, the best way to verify whether an Atom CPU is N450/D410/D510 is to check the host bridge device. Signed-off-by: Yong Wang <yong.y.wang@intel.com> Acked-by: Huaxu Wan <huaxu.wan@intel.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18netfilter: nf_ct_ftp: fix out of bounds read in update_nl_seq()Patrick McHardy
commit aaff23a95aea5f000895f50d90e91f1e2f727002 upstream. As noticed by Dan Carpenter <error27@gmail.com>, update_nl_seq() currently contains an out of bounds read of the seq_aft_nl array when looking for the oldest sequence number position. Fix it to only compare valid positions. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18netfilter: ebtables: enforce CAP_NET_ADMINFlorian Westphal
commit dce766af541f6605fa9889892c0280bab31c66ab upstream. normal users are currently allowed to set/modify ebtables rules. Restrict it to processes with CAP_NET_ADMIN. Note that this cannot be reproduced with unmodified ebtables binary because it uses SOCK_RAW. Signed-off-by: Florian Westphal <fwestphal@astaro.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18ASoC: Fix WM8350 DSP mode B configurationMark Brown
commit 5ee518ecbcb5934e284ea51a19a939c891f5f7ea upstream. We need to set the LRCLK inversion bit to select DSP mode. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18ALSA: atiixp: Specify codec for Foxconn RC4107MA-RS2Daniel T Chen
commit dfb12eeb0f04b37e5eb3858864d074af4ecd2ac7 upstream. BugLink: https://bugs.launchpad.net/ubuntu/+bug/498863 This mainboard needs ac97_codec=0. Tested-by: Apoorv Parle <apparle@yahoo.co.in> Signed-off-by: Daniel T Chen <crimsun@ubuntu.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18ALSA: ac97: Add Dell Dimension 2400 to Headphone/Line Jack Sense blacklistDaniel T Chen
commit af9a75dd1a1f8a9aa406466cc8bb16208120488a upstream. This model needs both 'Headphone Jack Sense' and 'Line Jack Sense' muted for audible playback, so just add it to the ad1981 jack sense blacklist. Tested-by: Pete <x41215201@gmail.com> Signed-off-by: Daniel T Chen <crimsun@ubuntu.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18ALSA: hda - Fix ALC861-VD capture source mixerTakashi Iwai
commit 9c0afc861a7228f718cb6a79fa7f9d46bf9ff300 upstream. The capture source or input source mixer element wasn't created properly for ALC861-VD codec due to the wrong NID passed to alc_auto_create_input_ctls(). References: Novell bnc#568305 http://bugzilla.novell.com/show_bug.cgi?id=568305 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18mmc_block: fix queue cleanupAdrian Hunter
commit 5fa83ce284a4b7cd9dcfadd01500b0ed4ab9b740 upstream. The main bug was that 'blk_cleanup_queue()' was called while the block device could still be in use, for example, because the card was removed while files were still open. In addition, to be sure that 'mmc_request()' will get called for all new requests (so it can error them out), the queue is emptied during cleanup. This is done after the worker thread is stopped to avoid racing with it. Finally, it is not a device error for this to be happening, so quiet the (sometimes very many) error messages. Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18mmc_block: fix probe error cleanup bugJarkko Lavinen
commit 0a74ff29b8dd8b748f8856352f9a9b5c6cc362cc upstream. If mmc_blk_set_blksize() fails mmc_blk_probe() the request queue and its thread have been set up and they need to be shut down properly before putting the disk. Signed-off-by: Jarkko Lavinen <jarkko.lavinen@nokia.com> Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18mmc_block: add dev_t initialization checkAnna Lemehova
commit 7d92df692994472cab6045bbd9d0e2c4afa4365f upstream. When a card is removed before mmc_blk_probe() has called add_disk(), then the minor field is uninitialized and has value 0. This caused mmc_blk_put() to always release devidx 0 even if 0 was still in use. Then the next mmc_blk_probe() used the first free idx of 0, which oopses in sysfs, since it is used by another card. Signed-off-by: Anna Lemehova <EXT-Anna.Lemehova@nokia.com> Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18kernel/signal.c: fix kernel information leak with print-fatal-signals=1Andi Kleen
commit b45c6e76bc2c72f6426c14bed64fdcbc9bf37cb0 upstream. When print-fatal-signals is enabled it's possible to dump any memory reachable by the kernel to the log by simply jumping to that address from user space. Or crash the system if there's some hardware with read side effects. The fatal signals handler will dump 16 bytes at the execution address, which is fully controlled by ring 3. In addition when something jumps to a unmapped address there will be up to 16 additional useless page faults, which might be potentially slow (and at least is not very efficient) Fortunately this option is off by default and only there on i386. But fix it by checking for kernel addresses and also stopping when there's a page fault. Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18dma-debug: allow DMA_BIDIRECTIONAL mappings to be synced with ↵Krzysztof Halasa
DMA_FROM_DEVICE and commit 42d53b4ff7d61487d18274ebdf1f70c1aef6f122 upstream. There is no need to perform full BIDIR sync (copying the buffers in case of swiotlb and similar schemes) if we know that the owner (CPU or device) hasn't altered the data. Addresses the false-positive reported at http://bugzilla.kernel.org/show_bug.cgi?id=14169 Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Cc: David Miller <davem@davemloft.net> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18lib/rational.c needs module.hSascha Hauer
commit 7ee3aebe31d2cb22c84e1c8f48182947b13a3607 upstream. lib/rational.c:62: warning: data definition has no type or storage class lib/rational.c:62: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' lib/rational.c:62: warning: parameter names (without types) in function declaration Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: WANG Cong <xiyou.wangcong@gmail.com> Cc: Oskar Schirmer <os@emlix.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18cgroups: fix 2.6.32 regression causing BUG_ON() in cgroup_diput()Dave Anderson
commit bd4f490a079730aadfaf9a728303ea0135c01945 upstream. The LTP cgroup test suite generates a "kernel BUG at kernel/cgroup.c:790!" here in cgroup_diput(): /* * if we're getting rid of the cgroup, refcount should ensure * that there are no pidlists left. */ BUG_ON(!list_empty(&cgrp->pidlists)); The cgroup pidlist rework in 2.6.32 generates the BUG_ON, which is caused when pidlist_array_load() calls cgroup_pidlist_find(): (1) if a matching cgroup_pidlist is found, it down_write's the mutex of the pre-existing cgroup_pidlist, and increments its use_count. (2) if no matching cgroup_pidlist is found, then a new one is allocated, it down_write's its mutex, and the use_count is set to 0. (3) the matching, or new, cgroup_pidlist gets returned back to pidlist_array_load(), which increments its use_count -- regardless whether new or pre-existing -- and up_write's the mutex. So if a matching list is ever encountered by cgroup_pidlist_find() during the life of a cgroup directory, it results in an inflated use_count value, preventing it from ever getting released by cgroup_release_pid_array(). Then if the directory is subsequently removed, cgroup_diput() hits the BUG_ON() when it finds that the directory's cgroup is still populated with a pidlist. The patch simply removes the use_count increment when a matching pidlist is found by cgroup_pidlist_find(), because it gets bumped by the calling pidlist_array_load() function while still protected by the list's mutex. Signed-off-by: Dave Anderson <anderson@redhat.com> Reviewed-by: Li Zefan <lizf@cn.fujitsu.com> Acked-by: Ben Blum <bblum@andrew.cmu.edu> Cc: Paul Menage <menage@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drivers/cpuidle/governors/menu.c: fix undefined reference to `__udivdi3'Stephen Hemminger
commit 5787536edf18e33d06e2bf038bfd0910f4def213 upstream. menu: use proper 64 bit math The new menu governor is incorrectly doing a 64 bit divide. Compile tested only Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Len Brown <len.brown@intel.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18rtc_cmos: convert shutdown to new pnp_driver->shutdownOGAWA Hirofumi
commit 004731b2c7c658d36bee167cb1e1a399c2cbccc9 upstream. commit abd6633c67925f90775bb74755f9c547e30f1f20 ("pnp: add a shutdown method to pnp drivers") adds shutdown method to bus driver blindly. With it, driver->shutdown is no longer valid. Use pnp_driver->shutdown instead. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14889 Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Reported-by: Malte Schröder <maltesch@gmx.de> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: David Hardeman <david@hardeman.nu> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm/i915: fix unused varAndrew Morton
commit 29bd0ae25f8cb96b63560c2cbccec77b425e1603 upstream. drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load': drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function Partly this is because gcc isn't smart enough. But `ll_base' does get used uninitialised in the DRM_DEBUG() call. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eric Anholt <eric@anholt.net> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm/i915: Select the correct BPC for LVDS on IronlakeZhao Yakui
commit e5a95eb778690bc864eb330202d2c1b974caaeb4 upstream. Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel, the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8. At the same time the BPC will be 8 when the output device is CRT/HDMI/DP. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm/i915: Make the BPC in FDI rx/transcoder be consistent with that in ↵Zhao Yakui
pipeconf on Ironlake commit 8faf3b317471179c02db339aa80955a2e88c036d upstream. Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm/i915: Enable/disable the dithering for LVDS based on VBT settingZhao Yakui
commit 898822ce9561ab9b58a7eb60580a162a83dadecd upstream. Enable/disable the dithering for LVDS based on VBT setting. On the 965/g4x platform the dithering flag is defined in LVDS register. And on the ironlake the dithering flag is defined in pipeconf register. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm: remove address mask param for drm_pci_alloc()Zhenyu Wang
commit e6be8d9d17bd44061116f601fe2609b3ace7aa69 upstream. drm_pci_alloc() has input of address mask for setting pci dma mask on the device, which should be properly setup by drm driver. And leave it as a param for drm_pci_alloc() would cause confusion or mistake would corrupt the correct dma mask setting, as seen on intel hw which set wrong dma mask for hw status page. So remove it from drm_pci_alloc() function. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm/i915: Permit pinning whilst the device is 'suspended'Chris Wilson
commit e3d8affb0d2d95f2da61e30ce86b33177feb91e8 upstream. As pinning (allocating and binding GTT memory) does not actually invoke GPU commands, it is safe, and indeed is attempted, during resumption from suspension: [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm/i915: fix order of fence release wrt flushingDaniel Vetter
commit 96b47b65594fe2365f73aede060cb5203561fed3 upstream. i915_gem_object_unbind had the ordering wrong. The other user, i915_gem_object_put_fence_reg already has the correct ordering. Results was usually corrupted pixmaps, especially garbled font glyphs after a suspend/resume (because this evicts everything). I'm still waiting for the feedback from the bug-reporters, but because this obviously fixes a bug (at least for me) I'm already submitting it. Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25406 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18drm/i915: Update LVDS connector status when receiving ACPI LID eventZhao Yakui
commit a2565377a5c31e25c77c7cabaf6752abe9a2d83a upstream. Dirk reports that nothing is displayed on LVDS when using ubuntu 9.1 after close/reopen the LID. And I also reproduce this issue on another laptop. After some tests and debug, it seems that it is related with that the LVDS status is not updated in time in course of suspend/resume. Now the LID state is used to check whether the LVDS is connected or disconnected. And when the LID is closed, it means that the LVDS is disconnected. When it is reopened, it means that the LVDS is connected. At the same time on some distributions the LID event is also used to put the system into suspend state. When the LID is closed, the system will enter the suspend state. When the LID is reopened, the system will be resumed. In such case when the LID is closed, user-space script will receive the LID notification event and detect the LVDS as disconnected. Then the system will enter the suspended state. When the LID is reopened, the system will be resumed. As the LVDS status is not updated in course of resume, it will cause that the LVDS connector is marked as unused and disabled. After the resume is finished,user-space script will try to configure the display mode for LVDS. But unfortunately as the LVDS status is not updated in time and it is still marked as disconnected, the LVDS and its corresponding CRTC will be disabled again in the function of drm_helper_disable_unused_functions after changing mode for LVDS. So we had better check and update the status of LVDS connector after receiving the LID notication event. Then after the system is resumed from suspended state, we can set the display mode for LVDS correctly. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Reported-by: Dirk Hohndel <hohndel@infradead.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18sunrpc: on successful gss error pipe write, don't return errorJeff Layton
commit 486bad2e40e938cd68fd853b7a9fa3115a9d3a4a upstream. When handling the gssd downcall, the kernel should distinguish between a successful downcall that contains an error code and a failed downcall (i.e. where the parsing failed or some other sort of problem occurred). In the former case, gss_pipe_downcall should be returning the number of bytes written to the pipe instead of an error. In the event of other errors, we generally want the initiating task to retry the upcall so we set msg.errno to -EAGAIN. An unexpected error code here is a bug however, so BUG() in that case. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18SUNRPC: Fix the return value in gss_import_sec_context()Trond Myklebust
commit b891e4a05ef6beac85465295a032431577c66b16 upstream. If the context allocation fails, it will return GSS_S_FAILURE, which is neither a valid error code, nor is it even negative. Return ENOMEM instead... Reported-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18SUNRPC: Fix up an error return value in gss_import_sec_context_kerberos()Trond Myklebust
commit 14ace024b1e16d2bb9445c8387494fbbd820a738 upstream. If the context allocation fails, the function currently returns a random error code, since the variable 'p' still points to a valid memory location. Ensure that it returns ENOMEM... Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18sunrpc: fix peername failed on closed listenerXiaotian Feng
commit b292cf9ce70d221c3f04ff62db5ab13d9a249ca8 upstream. There're some warnings of "nfsd: peername failed (err 107)!" socket error -107 means Transport endpoint is not connected. This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c], when kernel_getpeername returns -107. This means socket might be CLOSED. And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c] if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) { <snip> newxpt = xprt->xpt_ops->xpo_accept(xprt); <snip> So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE. Let's take a look at commit b0401d72, this commit has moved the close processing after do recvfrom method, but this commit also introduces this warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should close it, not accpet then close. Signed-off-by: Xiaotian Feng <dfeng@redhat.com> Cc: J. Bruce Fields <bfields@fieldses.org> Cc: Neil Brown <neilb@suse.de> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: David S. Miller <davem@davemloft.net> Cc: Nikola Ciprich <extmaillist@linuxbox.cz> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18nfsd: make sure data is on disk before calling ->fsyncChristoph Hellwig
commit 7211a4e859ad070b28545c06e0a6cb60b3b8aa31 upstream. nfsd is not using vfs_fsync, so I missed it when changing the calling convention during the 2.6.32 window. This patch fixes it to not only start the data writeout, but also wait for it to complete before calling into ->fsync. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18Revert "x86: Side-step lguest problem by only building cmpxchg8b_emu for ↵Rusty Russell
pre-Pentium" commit db677ffa5f5a4f15b9dad4d132b3477b80766d82 upstream. This reverts commit ae1b22f6e46c03cede7cea234d0bf2253b4261cf. As Linus said in 982d007a6ee: "There was something really messy about cmpxchg8b and clone CPU's, so if you enable it on other CPUs later, do it carefully." This breaks lguest for those configs, but we can fix that by emulating if we have to. Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14884 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18exofs: simple_write_end does not mark_inode_dirtyBoaz Harrosh
commit efd124b999fb4d426b30675f1684521af0872789 upstream. exofs uses simple_write_end() for it's .write_end handler. But it is not enough because simple_write_end() does not call mark_inode_dirty() when it extends i_size. So even if we do call mark_inode_dirty at beginning of write out, with a very long IO and a saturated system we might get the .write_inode() called while still extend-writing to file and miss out on the last i_size updates. So override .write_end, call simple_write_end(), and afterwords if i_size was changed call mark_inode_dirty(). It stands to logic that since simple_write_end() was the one extending i_size it should also call mark_inode_dirty(). But it looks like all users of simple_write_end() are memory-bound pseudo filesystems, who could careless about mark_inode_dirty(). I might submit a warning-comment patch to simple_write_end() in future. Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-18modules: Skip empty sections when exporting section notesBen Hutchings
commit 10b465aaf9536ee5a16652fa0700740183d48ec9 upstream. Commit 35dead4 "modules: don't export section names of empty sections via sysfs" changed the set of sections that have attributes, but did not change the iteration over these attributes in add_notes_attrs(). This can lead to add_notes_attrs() creating attributes with the wrong names or with null name pointers. Introduce a sect_empty() function and use it in both add_sect_attrs() and add_notes_attrs(). Reported-by: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Tested-by: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>