commit 14d33e7fa86a09138b745030097a48c396cf4e57 Author: Greg Kroah-Hartman Date: Thu Aug 30 23:21:01 2007 -0700 Linux 2.6.22.6 commit 233b8a1ed2ef8e17c12a6f328470cf11d64a756a Author: Kay Sievers Date: Wed Aug 22 15:15:51 2007 -0700 usb: add PRODUCT, TYPE to usb-interface events This fixes a regression for userspace programs that were relying on these events. Signed-off-by: Kay Sievers Cc: Andreas Jellinghaus Signed-off-by: Greg Kroah-Hartman commit 852ffe0acf89f959e8d35080bbd2bdc2d8f2e9e5 Author: Oliver Neukum Date: Wed Aug 22 15:15:43 2007 -0700 USB: fix DoS in pwc USB video driver the pwc driver has a disconnect method that waits for user space to close the device. This opens up an opportunity for a DoS attack, blocking the USB subsystem and making khubd's task busy wait in kernel space. This patch shifts freeing resources to close if an opened device is disconnected. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 8e62c5a411874691e8938fa439978de9fa7c58c8 Author: Alan Stern Date: Wed Aug 22 15:15:42 2007 -0700 USB: allow retry on descriptor fetch errors This patch (as964) was suggested by Steffen Koepf. It makes usb_get_descriptor() retry on all errors other than ETIMEDOUT, instead of only on EPIPE. This helps with some devices. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit cd7f435fa35f80ba07c867d7569a9bb3606e1692 Author: Tejun Heo Date: Wed Aug 22 15:12:55 2007 -0700 PCI: disable MSI on RX790 RX790 can't do MSI like its predecessors. Disable MSI on RX790. Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 41ef7dce0273066f384374cfc962c23f2d918d84 Author: Tejun Heo Date: Wed Aug 22 15:12:54 2007 -0700 PCI: disable MSI on RD580 RD580 can't do MSI like its predecessors. Disable MSI on RD580. Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 1674e24cbb06e511b3d4c37eb7c275d6e268bfc8 Author: Tejun Heo Date: Wed Aug 22 15:12:53 2007 -0700 PCI: disable MSI on RS690 RS690 can't do MSI like its predecessors. Disable MSI on RS690. Signed-off-by: Tejun Heo Cc: Henry Su Signed-off-by: Greg Kroah-Hartman commit 2124e37772002da46addd4ed6d13fcdec9717541 Author: Bernhard Kaindl Date: Wed Aug 22 15:12:51 2007 -0700 PCI: lets kill the 'PCI hidden behind bridge' message Adrian Bunk wrote: > Alois NeÅ¡por wrote >> PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0b) (try 'pci=assign-busses') >> Please report the result to linux-kernel to fix this permanently" >> >> dmesg: >> "Yenta: Raising subordinate bus# of parent bus (#0a) from #0b to #0e" >> without pci=assign-busses and nothing with pci=assign-busses. > > Bernhard? Ok, lets kill the message. As Alois NeÅ¡por also saw, that's fixed up by Yenta, so PCI does not have to warn about it. PCI could still warn about it if is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have not seen a report where this would have been the case so I think we can spare the kernel of that check (removes ~300 lines of asm) unless debugging is done. History: The whole check was added in the days before we had the fixup for this in Yenta and pci=assign-busses was the only way to get CardBus cards detected on many (not all) of the machines which give this warning. In theory, there could be cases when this warning would be triggered and it's not cardbus, then the warning should still apply, but I think this should only be the case when working on a completely broken PCI setup, but one may have already enabled the debug code in drivers/pci and the patched check would then trigger. I do not sign this off yet because it's completely untested so far, but everyone is free to test it (with the #ifdef DEBUG replaced by #if 1 and pr_debug( changed to printk(. We may also dump the whole check (remove everything within the #ifdef from the source) if that's perferred. On Alois NeÅ¡por's machine this would then (only when debugging) this message: "PCI: Bus #0b (-#0e) is partially hidden behind transparent bridge #0a (-#0b)" "partially" should be in the message on his machine because #0b of #0b-#0e is reachable behind #0a-#0b, but not #0c-#0e. But that differentiation is now moot anyway because the fixup in Yenta takes care of it as far as I could see so far, which means that unless somebody is debugging a totally broken PCI setup, this message is not needed anymore, not even for debugging PCI. Ok, here the patch with the following changes: * Refined to say that the bus is only partially hidden when the parent bus numbers are not totally way off (outside of) the child bus range * remove the reference to pci=assign-busses and the plea to report it We could add a pure source code-only comment to keep a reference to pci=assign-busses the in case when this is triggered by someone who is debugging the cause of this message and looking the way to solve it. From: Bernhard Kaindl Signed-off-by: Greg Kroah-Hartman commit 19de71f9fa023cb8a2b067a6db2f57ee4fad9f5d Author: Konstantin Sharlaimov Date: Tue Aug 21 21:20:25 2007 -0700 PPP: Fix PPP buffer sizing. This patch addresses the issue with "osize too small" errors in mppe encryption. The patch fixes the issue with wrong output buffer size being passed to ppp decompression routine. -------------------- As pointed out by Suresh Mahalingam, the issue addressed by ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet. The size of allocated output buffer is correct, however it size passed to ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that. -------------------- Signed-off-by: Konstantin Sharlaimov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8385cffd22359ad561a173accefeb354bd606ce4 Author: Ilpo Järvinen Date: Tue Aug 21 21:18:07 2007 -0700 TCP: Fix TCP handling of SACK in bidirectional flows. It's possible that new SACK blocks that should trigger new LOST markings arrive with new data (which previously made is_dupack false). In addition, I think this fixes a case where we get a cumulative ACK with enough SACK blocks to trigger the fast recovery (is_dupack would be false there too). I'm not completely pleased with this solution because readability of the code is somewhat questionable as 'is_dupack' in SACK case is no longer about dupacks only but would mean something like 'lost_marker_work_todo' too... But because of Eifel stuff done in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to the if statement which seems attractive solution. Nevertheless, I didn't like adding another variable just for that either... :-) Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 783366ad4b212cde069c50903494eb6a6b83958c Author: Ilpo Järvinen Date: Tue Aug 21 21:17:03 2007 -0700 TCP: Fix TCP rate-halving on bidirectional flows. Actually, the ratehalving seems to work too well, as cwnd is reduced on every second ACK even though the packets in flight remains unchanged. Recoveries in a bidirectional flows suffer quite badly because of this, both NewReno and SACK are affected. After this patch, rate halving is performed for ACK only if packets in flight was supposedly changed too. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e061467dc5b4c78d4fe61ea6d7a0c848e22882d7 Author: David Miller Date: Tue Aug 21 21:14:45 2007 -0700 TCP: Do not autobind ports for TCP sockets [TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg(). As discovered by Evegniy Polyakov, if we try to sendmsg after a connection reset, we can do incredibly stupid things. The core issue is that inet_sendmsg() tries to autobind the socket, but we should never do that for TCP. Instead we should just go straight into TCP's sendmsg() code which will do all of the necessary state and pending socket error checks. TCP's sendpage already directly vectors to tcp_sendpage(), so this merely brings sendmsg() in line with that. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5299059b0c2e508d01fbe78f6fe43b94d9139373 Author: David Miller Date: Tue Aug 21 21:12:32 2007 -0700 SPARC64: Fix sparc64 PCI config accesses on sun4u [SPARC64]: Fix sun4u PCI config space accesses on sun4u. Don't provide fake PCI config space for sun4u. Also, put back the funny host controller space handling that at least Sabre needs. You have to read PCI host controller registers at their nature size otherwise you get zeros instead of correct values. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 08acaae698d7b5c4da0abe6a879d014117585065 Author: David Miller Date: Tue Aug 21 21:11:14 2007 -0700 SPARC64: Fix sparc64 task stack traces. It didn't handle that case at all, and now dump_stack() can be implemented directly as show_stack(current, NULL) Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b13778e09272469203cb8d100defd8047a2117df Author: Herbert Xu Date: Tue Aug 21 21:09:15 2007 -0700 NET: Fix missing rcu unlock in __sock_create() [NET]: Fix unbalanced rcu_read_unlock in __sock_create The recent RCU work created an unbalanced rcu_read_unlock in __sock_create. This patch fixes that. Reported by oleg 123. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6ec3b79f45f813c9957c2a7af25e0e1ec53e6f1a Author: Herbert Xu Date: Tue Aug 21 21:07:30 2007 -0700 SNAP: Fix SNAP protocol header accesses. The snap_rcv code reads 5 bytes so we should make sure that we have 5 bytes in the head before proceeding. Based on diagnosis and fix by Evgeniy Polyakov, reported by Alan J. Wylie. Patch also kills the skb->sk assignment before kfree_skb since it's redundant. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8c1bc44eadcf0ef011a29f54a61d979dd84a6bac Author: Chuck Ebbert Date: Tue Aug 21 21:05:14 2007 -0700 Netfilter: Missing Kbuild entry for netfilter Author: Chuck Ebbert Add xt_statistic.h to the list of headers to install. Apparently needed to build newer versions of iptables. Signed-off-by: Chuck Ebbert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 14d5c15ac1e080baaa861fbcde342fda3c549bdd Author: David Miller Date: Tue Aug 21 21:04:07 2007 -0700 Fix soft-fp underflow handling. The underflow exception cases were wrong. This is one weird area of ieee1754 handling in that the underflow behavior changes based upon whether underflow is enabled in the trap enable mask of the FPU control register. As a specific case the Sparc V9 manual gives us the following description: -------------------- If UFM = 0: Underflow occurs if a nonzero result is tiny and a loss of accuracy occurs. Tininess may be detected before or after rounding. Loss of accuracy may be either a denormalization loss or an inexact result. If UFM = 1: Underflow occurs if a nonzero result is tiny. Tininess may be detected before or after rounding. -------------------- What this amounts to in the packing case is if we go subnormal, we set underflow if any of the following are true: 1) rounding sets inexact 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too 3) underflow is set in FPU control register trap-enable mask The initially discovered example was "DBL_MIN / 16.0" which incorrectly generated an underflow. It should not, unless underflow is set in the trap-enable mask of the FPU csr. Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above. However, if underflow is set in the trap enable mask, only underflow should be set and reported as a trap. That is handled properly by the prioritization logic in arch/sparc{,64}/math-emu/math.c:record_exception(). Based upon a report and test case from Jakub Jelinek. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f7d75b68abd28e63dd982bb6748bc5d32a289c42 Author: Ilpo Jarvinen Date: Tue Aug 21 21:02:27 2007 -0700 IPv6: Invalid semicolon after if statement Author: Ilpo Järvinen A similar fix to netfilter from Eric Dumazet inspired me to look around a bit by using some grep/sed stuff as looking for this kind of bugs seemed easy to automate. This is one of them I found where it looks like this semicolon is not valid. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6f333f6314bf003ee460abc633ea5037d1e53f06 Author: Wei Yongjun Date: Tue Aug 21 21:01:01 2007 -0700 IPV6: Fix kernel panic while send SCTP data with IP fragments If ICMP6 message with "Packet Too Big" is received after send SCTP DATA, kernel panic will occur when SCTP DATA is send again. This is because of a bad dest address when call to skb_copy_bits(). The messages sequence is like this: Endpoint A Endpoint B <------- SCTP DATA (size=1432) ICMP6 message -------> (Packet Too Big pmtu=1280) <------- Resend SCTP DATA (size=1432) ------------kernel panic--------------- printing eip: c05be62a *pde = 00000000 Oops: 0002 [#1] SMP Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010282 (2.6.23-rc2 #1) EIP is at skb_copy_bits+0x4f/0x1ef eax: 000004d0 ebx: ce12a980 ecx: 00000134 edx: cfd5a880 esi: c8246858 edi: 00000000 ebp: c0759b14 esp: c0759adc ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000) Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880 d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521 000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0x1b8/0x289 [] die+0x113/0x246 [] do_page_fault+0x4ad/0x57e [] error_code+0x72/0x78 [] ip6_output+0x8e5/0xab2 [ipv6] [] ip6_xmit+0x2ea/0x3a3 [ipv6] [] sctp_v6_xmit+0x248/0x253 [sctp] [] sctp_packet_transmit+0x53f/0x5ae [sctp] [] sctp_outq_flush+0x555/0x587 [sctp] [] sctp_retransmit+0xf8/0x10f [sctp] [] sctp_icmp_frag_needed+0x57/0x5b [sctp] [] sctp_v6_err+0xcd/0x148 [sctp] [] icmpv6_notify+0xe6/0x167 [ipv6] [] icmpv6_rcv+0x7d7/0x849 [ipv6] [] ip6_input+0x1dc/0x310 [ipv6] [] ipv6_rcv+0x294/0x2df [ipv6] [] netif_receive_skb+0x2d2/0x335 [] process_backlog+0x7f/0xd0 [] net_rx_action+0x96/0x17e [] __do_softirq+0x64/0xcd [] do_softirq+0x5c/0xac ======================= Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01 EIP: [] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc Kernel panic - not syncing: Fatal exception in interrupt Arnaldo says: ==================== Thanks! I'm to blame for this one, problem was introduced in: b0e380b1d8a8e0aca215df97702f99815f05c094 /* * Copy a block of the IP datagram. */ - if (skb_copy_bits(skb, ptr, frag->h.raw, len)) + if (skb_copy_bits(skb, ptr, skb_transport_header(skb), len)) BUG(); left -= len; ==================== Signed-off-by: Wei Yongjun Acked-by: YOSHIFUJI Hideaki Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fe1cfa1ebe5181225911707cf182c19f71cf5ab8 Author: Gerrit Renker Date: Tue Aug 21 20:53:27 2007 -0700 DCCP: Fix DCCP GFP_KERNEL allocation in atomic context This fixes the following bug reported in syslog: [ 4039.051658] BUG: sleeping function called from invalid context at /usr/src/davem-2.6/mm/slab.c:3032 [ 4039.051668] in_atomic():1, irqs_disabled():0 [ 4039.051670] INFO: lockdep is turned off. [ 4039.051674] [] show_trace_log_lvl+0x1a/0x30 [ 4039.051687] [] show_trace+0x12/0x14 [ 4039.051691] [] dump_stack+0x16/0x18 [ 4039.051695] [] __might_sleep+0xaf/0xbe [ 4039.051700] [] __kmalloc+0xb1/0xd0 [ 4039.051706] [] ccid2_hc_tx_alloc_seq+0x35/0xc3 [dccp_ccid2] [ 4039.051717] [] ccid2_hc_tx_packet_sent+0x27f/0x2d9 [dccp_ccid2] [ 4039.051723] [] dccp_write_xmit+0x1eb/0x338 [dccp] [ 4039.051741] [] dccp_sendmsg+0x113/0x18f [dccp] [ 4039.051750] [] inet_sendmsg+0x2e/0x4c [ 4039.051758] [] sock_aio_write+0xd5/0x107 [ 4039.051766] [] do_sync_write+0xcd/0x11c [ 4039.051772] [] vfs_write+0x118/0x11f [ 4039.051840] [] sys_write+0x3d/0x64 [ 4039.051845] [] syscall_call+0x7/0xb [ 4039.051848] ======================= The problem was that GFP_KERNEL was used; fixed by using gfp_any(). Signed-off-by: Gerrit Renker Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b0f4f52ccbc546a587b5306a317be086d5fcadd8 Author: Oleg Nesterov Date: Wed Aug 22 14:01:48 2007 -0700 signalfd: make it group-wide, fix posix-timers scheduling With this patch any thread can dequeue its own private signals via signalfd, even if it was created by another sub-thread. To do so, we pass "current" to dequeue_signal() if the caller is from the same thread group. This also fixes the scheduling of posix timers broken by the previous patch. If the caller doesn't belong to this thread group, we can't handle __SI_TIMER case properly anyway. Perhaps we should forbid the cross-process signalfd usage and convert ctx->tsk to ctx->sighand. Signed-off-by: Oleg Nesterov Cc: Benjamin Herrenschmidt Cc: Davide Libenzi Cc: Ingo Molnar Cc: Michael Kerrisk Cc: Roland McGrath Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 68159e50ef135abc07fb2b866ade8655e93d17cb Author: Oleg Nesterov Date: Wed Aug 22 14:01:42 2007 -0700 signalfd: fix interaction with posix-timers dequeue_signal: if (__SI_TIMER) { spin_unlock(&tsk->sighand->siglock); do_schedule_next_timer(info); spin_lock(&tsk->sighand->siglock); } Unless tsk == curent, this is absolutely unsafe: nothing prevents tsk from exiting. If signalfd was passed to another process, do_schedule_next_timer() is just wrong. Add yet another "tsk == current" check into dequeue_signal(). This patch fixes an oopsable bug, but breaks the scheduling of posix timers if the shared __SI_TIMER signal was fetched via signalfd attached to another sub-thread. Mostly fixed by the next patch. Signed-off-by: Oleg Nesterov Cc: Benjamin Herrenschmidt Cc: Davide Libenzi Cc: Ingo Molnar Cc: Michael Kerrisk Cc: Roland McGrath Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f24e131c7e06c4f0bbb69bebf66d16bde48c3f31 Author: Zachary Amsden Date: Wed Aug 22 14:02:02 2007 -0700 i386: fix lazy mode vmalloc synchronization for paravirt Found this looping Ubuntu installs with VMI. If unlucky enough to hit a vmalloc sync fault during a lazy mode operation (from an IRQ handler for a module which was not yet populated in current page directory, or from inside copy_one_pte, which touches swap_map, and hit in an unused 4M region), the required PDE update would never get flushed, causing an infinite page fault loop. This bug affects any paravirt-ops backend which uses lazy updates, I believe that makes it a bug in Xen, VMI and lguest. It only happens on LOWMEM kernels. Touching vmalloc memory in the middle of a lazy mode update can generate a kernel PDE update, which must be flushed immediately. The fix is to leave lazy mode when doing a vmalloc sync. Signed-off-by: Zachary Amsden Cc: Andi Kleen Cc: Jeremy Fitzhardinge Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6f157f740ceb977982d36abbf2f54ffbc3964190 Author: Jeff Dike Date: Wed Aug 22 14:01:53 2007 -0700 uml: fix previous request size limit fix The previous patch which limited the number of sectors in a single request to a COWed device was correct in concept, but the limit was implemented in the wrong place. By putting it in ubd_add, it covered the cases where the COWing was specified on the command line. However, when the command line only has the COW file specified, the fact that it's a COW file isn't known until it's opened, so the limit is missed in these cases. This patch moves the sector limit from ubd_add to ubd_open_dev. Signed-off-by: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7405863e9166369e3ee87aa8f765566b693e2663 Author: Stephen Hemminger Date: Tue Aug 21 11:10:22 2007 -0700 sky2: don't clear phy power bits There are special PHY settings available on Yukon EC-U chip that should not get cleared. This should solve mysterious errors on some motherboards (like Gigabyte DS-3). Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman commit d5e756e26a271662bab6a10df75f2b3f9bc54ef7 Author: Herbert Xu Date: Tue Aug 21 14:22:55 2007 +0800 NET: Share correct feature code between bridging and bonding [NET]: Share correct feature code between bridging and bonding http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the bonding driver may produce bogus combinations of the checksum flags and SG/TSO. For example, if you bond devices with NETIF_F_HW_CSUM and NETIF_F_IP_CSUM you'll end up with a bonding device that has neither flag set. If both have TSO then this produces an illegal combination. The bridge device on the other hand has the correct code to deal with this. In fact, the same code can be used for both. So this patch moves that logic into net/core/dev.c and uses it for both bonding and bridging. In the process I've made small adjustments such as only setting GSO_ROBUST if at least one constituent device supports it. Signed-off-by: Herbert Xu Acked-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1db5759e2d29c90d99659e132d4a137e20460061 Author: Mark Fasheh Date: Thu Aug 16 17:16:04 2007 -0700 ocfs2: Fix bad source start calculation during kernel writes [PATCH] ocfs2: Fix bad source start calculation during kernel writes For in-kernel writes ocfs2_get_write_source() should be starting the buffer at a page boundary as the math in ocfs2_map_and_write_user_data() will pad it back out to the correct write offset. Instead, we were passing the raw offset, which caused ocfs2_map_and_write_user_data() start too far into the buffer, resulting in corruptions from nfs client writes. Signed-off-by: Mark Fasheh Signed-off-by: Greg Kroah-Hartman