[PATCH] rtc: Remove unused RTC_DEVICE_NAME_SIZE
The last usage was removed in 5c82a6ae0 when rtc_device.name
was removed
Signed-off-by: Cole Robinson
---
Just noticed this when looking at commits a few months back...
include/linux/rtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 41319a2e409b..fc6c90b57be0 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -87,7 +87,6 @@ struct rtc_class_ops {
int (*set_offset)(struct device *, long offset);
};
-#define RTC_DEVICE_NAME_SIZE 20
typedef struct rtc_task {
void (*func)(void *private_data);
void *private_data;
--
2.14.3
Re: [PATCH 0/3] fix reuseaddr regression
On 09/18/2017 12:28 PM, jo...@toxicpanda.com wrote: > I introduced a regression when reworking the fastreuse port stuff that allows > bind conflicts to occur once a reuseaddr socket successfully opens on an > existing tb. The root cause is I reversed an if statement which caused us to > set the tb as if there were no owners on the socket if there were, which > obviously is not correct. > > Dave I have follow up patches that will add a selftest for this case and I ran > the other reuseport related tests as well. These need to go in pretty quickly > as it breaks kvm, I've marked them for stable. Sorry for the regression, > To clarify, it doesn't really break KVM specifically, but it breaks a port collision detection idiom that libvirt depends on to successfully launch qemu/xen/... VMs in certain cases. Thanks, Cole
Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
On 09/15/2017 01:51 PM, Josef Bacik wrote: > Finally got access to a box to run this down myself. This patch on top of > the other patches fixes the problem for me, could you verify it works for > you? Thanks, > Yup I can confirm that patch fixes things when applied on top of the previous 3 patches. Thanks! Please tag those patches for stable releases if appropriate, this is affecting a decent amount of libvirt users Thanks, Cole
Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
On 09/13/2017 03:44 PM, Josef Bacik wrote: > Alright thanks, this should fix it. > Still no luck with all three patches applied to fedora 4.12.8-300 RPM. Pretty sure I didn't mess up the testing but since I rarely do kernel builds it's not impossible... Thanks, Cole
Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
On 09/13/2017 01:40 PM, Cole Robinson wrote: > On 09/13/2017 01:28 PM, Josef Bacik wrote: >> Sorry I thought I had made this other fix, can you apply this on top of the >> other one and try that? I have more things to try if this doesn’t work, >> sorry you are playing go between, but I want to make sure I know _which_ fix >> actually fixes the problem, and then clean up in followup patches. Thanks, >> > > I'm the bug reporter. I'll combine the two patches and report back > Nope, issue is still present with both patches applied. Tried my own build and a package Laura provided Thanks, Cole
Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
On 09/13/2017 01:28 PM, Josef Bacik wrote: > Sorry I thought I had made this other fix, can you apply this on top of the > other one and try that? I have more things to try if this doesn’t work, > sorry you are playing go between, but I want to make sure I know _which_ fix > actually fixes the problem, and then clean up in followup patches. Thanks, > I'm the bug reporter. I'll combine the two patches and report back Thanks, Cole
Re: [Qemu-devel] sending SEGV to qemu crashes host kernel in Fedora 19
On 07/08/2013 09:11 PM, Dave Airlie wrote: > On Tue, Jul 9, 2013 at 10:35 AM, Dave Airlie wrote: >> Hi, >> >> F19 >> kernel-3.9.8-300.fc19.x86_64 >> qemu-kvm-1.4.2-4.fc19.x86_64 >> >> If I start a complete F19 install in the guest and send the qemu >> process a SEGV signal, the host kernel starts giving me random kmalloc >> errors soon after, if I send a normal kill signal things seem fine. >> >> CPU is Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, on a HP 220z workstation. >> >> I initially blamed bad RAM but this reproduces everytime, and I >> swapped DIMMs around >> >> I haven't tested with upstream kernel/qemu yet, but I wondered if >> anyone else has seen this. >> >> I noticed this because some work I was doing was segfaulting my qemu >> and then my machine would die a few mins later. > > Of course now I read my fedora kernel emails and notice vhost_net does > bad things, > > disabling vhost_net seems to make it work fine, hopefully the next > Fedora kernel will bring the magic fixes. > That issue and another nasty crasher are being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=980254 - Cole -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
