- 26 Sep, 2007 7 commits
-
-
Roman Zippel authored
commit f82f3f94 in mainline. Avoid setting the value if the symbol doesn't need to be changed or can't be changed. Later choices may change the dependencies and thus the possible input range. make oldconfig from a 2.6.22 .config with CONFIG_HOTPLUG_CPU not set was in some configurations setting CONFIG_HOTPLUG_CPU=y without asking, even when there was no actual requirement for CONFIG_HOTPLUG_CPU. This was triggered by SUSPEND_SMP that does a select HOTPLUG_CPU. Signed-off-by:
Roman Zippel <zippel@linux-m68k.org> Tested-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Oleg Nesterov authored
commit 60187d27 in mainline. Spotted by taoyue <yue.tao@windriver.com> and Jeremy Katz <jeremy.katz@windriver.com>. collect_signal: sigqueue_free: list_del_init(&first->list); if (!list_empty(&q->list)) { // not taken } q->flags &= ~SIGQUEUE_PREALLOC; __sigqueue_free(first); __sigqueue_free(q); Now, __sigqueue_free() is called twice on the same "struct sigqueue" with the obviously bad implications. In particular, this double free breaks the array_cache->avail logic, so the same sigqueue could be "allocated" twice, and the bug can manifest itself via the "impossible" BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free/send_sigqueue. Hopefully this can explain these mysterious bug-reports, see http://marc.info/?t=118766926500003 http://marc.info/?t=118466273000005 Alexey Dobriyan reports this patch makes the difference for the testcase, but nobody has an access to the application which opened the problems originally. Also, this patch removes tasklist lock/unlock, ->siglock is enough. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: taoyue <yue.tao@windriver.com> Cc: Jeremy Katz <jeremy.katz@windriver.com> Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Alexey Dobriyan <adobriyan@sw.ru> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Oleg Nesterov authored
commit b07e35f9 in mainline tree Spotted by Marcin Kowalczyk <qrczak@knm.org.pl>. sys_setpgid(child) fails if the child was forked by sub-thread. Fix the "is it our child" check. The previous commit ee0acf90 was not complete. (this patch asks for the new same_thread_group() helper, but mainline doesn't have it yet). Signed-off-by:
Roland McGrath <roland@redhat.com> Tested-by:
"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> Signed-off-by:
-
Trent Piepho authored
cherry picked from commit 6175e487 b2c2-flexcop: fix Airstar HD5000 tuning regression Git changeset 6bdcc6e6 dropped the stand-alone lgh06xf module, whose functionality was absorbed into the dvb-pll module. However, there was a minor difference between the code in lgh06xf and dvb-pll, which caused a regression in b2c2-flexcop devices using the LG-H06xF NIM. dvb-pll will probe for the presence of an i2c pll chip by performing a single byte read, the lgh06xf driver did not do this. Unfortunately, the code in flexcop-i2c.c does not currently support 1 byte or 0 byte reads as a probe. Such probes with the current code will always fail. In order to work around this problem, and restore proper functionality of the Airstar HD5000 device, this hack was created to make the probe appear to succeed. The single byte read in dvb_pll_attach is the only place where such a probe would ever occur, so this change is safe, and will not affect any other devices. Of course, if one knew how to actually perform the read operation, it would be better to go that route. In the meantime, however, we must apply this workaround, in order to prevent the regression that causes tuning to fail on the Airstar HD5000 ATSC device. Thanks to Jarod Wilson, who had originally reported this regression, and to Geoffrey Hausheer, whose original workaround patch led us to find the actual cause of the problem. Signed-off-by:
Trent Piepho <xyzzy@speakeasy.org> Cc: Geoffrey Hausheer <inli3epy93n@phracturedblue.com> Acked-by:
Jarod Wilson <jwilson@redhat.com> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
Andreas Arens authored
cherry picked from commit c545d6ad Update get_dvb_firmware script for the new location of the tda10046 firmware. The old location doesn't work anymore. Signed-off-by:
Andreas Arens <ari@goron.de> Signed-off-by:
-
Michael Krufky authored
cherry picked from commit 302170a4 get_dvb_firmware: update script for new location of sp8870 firmware This url is no longer valid: http://www.technotrend.de/new/217g/tt_Premium_217g.zip Replace with: http://www.softwarepatch.pl/9999ccd06a4813cb827dbb0005071c71/tt_Premium_217g.zip Thanks-to: Tobias Stoeber <tobi@to-st.de> Signed-off-by:
-
Hans Verkuil authored
cherry picked from commit c3624f99 ivtv: fix VIDIOC_S_FBUF support: new OSD values were never actually set. The values set with VIDIOC_S_FBUF were not actually used until the next VIDIOC_S_FMT. Fixed. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
- 25 Sep, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
Takashi Iwai authored
changeset ccec6e2c in mainline. Use seq_file for the proc file read/write of snd-page-alloc module. This automatically fixes bugs in the old proc code. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
- 21 Sep, 2007 2 commits
-
-
Chris Wright authored
-
Andi Kleen authored
Strictly it's only needed for eax. It actually does a little more than strictly needed -- the other registers are already zero extended. Also remove the now unnecessary and non functional compat task check in ptrace. This is CVE-2007-4573 Found by Wojciech Purczynski Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
- 31 Aug, 2007 28 commits
-
-
Greg Kroah-Hartman authored
-
Kay Sievers authored
This fixes a regression for userspace programs that were relying on these events. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Cc: Andreas Jellinghaus <aj@ciphirelabs.com> Signed-off-by:
-
Oliver Neukum authored
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 <oneukum@suse.de> Signed-off-by:
-
Alan Stern authored
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 <stern@rowland.harvard.edu> Signed-off-by:
-
Tejun Heo authored
RX790 can't do MSI like its predecessors. Disable MSI on RX790. Signed-off-by:
Tejun Heo <htejun@gmail.com> Signed-off-by:
-
Tejun Heo authored
RD580 can't do MSI like its predecessors. Disable MSI on RD580. Signed-off-by:
Tejun Heo <teheo@suse.de> Signed-off-by:
-
Tejun Heo authored
RS690 can't do MSI like its predecessors. Disable MSI on RS690. Signed-off-by:
-
Bernhard Kaindl authored
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 <bk@suse.de> Signed-off-by: -
Konstantin Sharlaimov authored
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 <konstantin.sharlaimov@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ilpo Järvinen authored
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 <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Ilpo Järvinen authored
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:
-
David Miller authored
[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 Miller authored
[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 Miller authored
It didn't handle that case at all, and now dump_stack() can be implemented directly as show_stack(current, NULL) Signed-off-by:
-
Herbert Xu authored
[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 <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
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:
-
Chuck Ebbert authored
Author: Chuck Ebbert <cebbert@redhat.com> Add xt_statistic.h to the list of headers to install. Apparently needed to build newer versions of iptables. Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
David Miller authored
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: -
Ilpo Jarvinen authored
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> 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:
-
Wei Yongjun authored
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:[<c05be62a>] 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: [<c0405e1d>] show_trace_log_lvl+0x1a/0x2f [<c0405ecd>] show_stack_log_lvl+0x9b/0xa3 [<c040608d>] show_registers+0x1b8/0x289 [<c0406271>] die+0x113/0x246 [<c0625dbc>] do_page_fault+0x4ad/0x57e [<c0624642>] error_code+0x72/0x78 [<d09bc521>] ip6_output+0x8e5/0xab2 [ipv6] [<d09bcec1>] ip6_xmit+0x2ea/0x3a3 [ipv6] [<d0a3f2ca>] sctp_v6_xmit+0x248/0x253 [sctp] [<d0a3c934>] sctp_packet_transmit+0x53f/0x5ae [sctp] [<d0a34bf8>] sctp_outq_flush+0x555/0x587 [sctp] [<d0a34d3c>] sctp_retransmit+0xf8/0x10f [sctp] [<d0a3d183>] sctp_icmp_frag_needed+0x57/0x5b [sctp] [<d0a3ece2>] sctp_v6_err+0xcd/0x148 [sctp] [<d09cf1ce>] icmpv6_notify+0xe6/0x167 [ipv6] [<d09d009a>] icmpv6_rcv+0x7d7/0x849 [ipv6] [<d09be240>] ip6_input+0x1dc/0x310 [ipv6] [<d09be965>] ipv6_rcv+0x294/0x2df [ipv6] [<c05c3789>] netif_receive_skb+0x2d2/0x335 [<c05c5733>] process_backlog+0x7f/0xd0 [<c05c58f6>] net_rx_action+0x96/0x17e [<c042e722>] __do_softirq+0x64/0xcd [<c0406f37>] 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 <f3> a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01 EIP: [<c05be62a>] 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: b0e380b1 /* * 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 <yjwei@cn.fujitsu.com> Acked-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by:
-
Gerrit Renker authored
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] [<c0104c0f>] show_trace_log_lvl+0x1a/0x30 [ 4039.051687] [<c0104d4d>] show_trace+0x12/0x14 [ 4039.051691] [<c0104d65>] dump_stack+0x16/0x18 [ 4039.051695] [<c011371e>] __might_sleep+0xaf/0xbe [ 4039.051700] [<c0157b66>] __kmalloc+0xb1/0xd0 [ 4039.051706] [<f090416f>] ccid2_hc_tx_alloc_seq+0x35/0xc3 [dccp_ccid2] [ 4039.051717] [<f09048d6>] ccid2_hc_tx_packet_sent+0x27f/0x2d9 [dccp_ccid2] [ 4039.051723] [<f085486b>] dccp_write_xmit+0x1eb/0x338 [dccp] [ 4039.051741] [<f085603d>] dccp_sendmsg+0x113/0x18f [dccp] [ 4039.051750] [<c03907fc>] inet_sendmsg+0x2e/0x4c [ 4039.051758] [<c033a47d>] sock_aio_write+0xd5/0x107 [ 4039.051766] [<c015abc1>] do_sync_write+0xcd/0x11c [ 4039.051772] [<c015b296>] vfs_write+0x118/0x11f [ 4039.051840] [<c015b932>] sys_write+0x3d/0x64 [ 4039.051845] [<c0103e7c>] syscall_call+0x7/0xb [ 4039.051848] ======================= The problem was that GFP_KERNEL was used; fixed by using gfp_any(). Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
-
Oleg Nesterov authored
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 authored
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: -
Zachary Amsden authored
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 <zach@vmware.com> Cc: Andi Kleen <ak@suse.de> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Jeff Dike authored
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 <jdike@linux.intel.com> Signed-off-by:
-
Stephen Hemminger authored
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 <shemminger@linux-foundation.org> Signed-off-by:
-
Herbert Xu authored
[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:
-
Mark Fasheh authored
[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 <mark.fasheh@oracle.com> Signed-off-by:
-
- 22 Aug, 2007 1 commit
-
-
Greg Kroah-Hartman authored
-
