Hi,
I wanted to check with you if you had a time to go through my previous
email,
Let me know your thoughts about acquiring this email list
Regards,
*Olivia*
______________________________________________________________________________________________
Hi,
I hope you are the right person to discuss about *Healthcare Leads*, which
includes complete contact details, and tele-verified email addresses.
Please find the Leads Breakdown Chart below:
*Criteria*
*Counts*
*Criteria*
*Counts*
*Criteria*
*Counts*
Allergy immunology
5,064
Healthcare Technology
20,540
Plastic surgery
8,371
Anesthesiology
30,155
Nephrology
6,606
Preventive medicine
6,642
Cardiology
24,577
Neurological surgery
7,066
Psychiatry
4,315
Dermatology
8,467
Neurology
13,354
Radiology
32,763
Emergency medicine
22,300
Obgyn
35,163
Surgery
39,517
Endocrinology diabetes metabolism
3,756
Oncology
17,881
Urology
10,135
Family practice1
62,544
Ophthalmology
15,237
Physician
100,000
Gastroenterology
11,913
Orthopedics
22,145
Doctors
128,000
General practice
12,957
Other
15,559
Dentists
150,200
Geriatrics Doctors
9,634
Otolaryngology
9,539
Osteopathic
25,000
Infectious disease
5,677
Pathology
15,467
Acupuncture
5,000
Internal medicine1
120,029
Pediatrics
55,684
Chiropractors
11,000
Haematology Doctors
12,850
Physical medicine
8,437
Rheumatology
5,000
*Data Fields:* Every lead includes Name, Company, Job Title, Website,
Physical Address, Industry, *Phone Number and Verified/Opt-In Email
Address.* Please let me know if you have any queries about our custom
opt-in list and I would love to answer them.
Kindly share your thoughts.
Warm Regards,
*Olivia Stewart*
*Marketing Executive *
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
We respect your privacy, if you want to remove it from this list. Please
reply with the subject line as “Leave Out”.
This series includes 6 types of fixes:
- Patch 1 fixes v4 mapped in v6 addresses support for the userspace PM,
when asking to delete a subflow. It was done everywhere else, but not
there. Patch 2 validates the modification, thanks to a subtest in
mptcp_join.sh. These patches can be backported up to v5.19.
- Patch 3 is a small fix for a recent bug-fix patch, just to avoid
printing an irrelevant warning (pr_warn()) once. It can be backported
up to v5.6, alongside the bug-fix that has been introduced in the
v6.8-rc5.
- Patches 4 to 6 are fixes for bugs found by Paolo while working on
TCP_NOTSENT_LOWAT support for MPTCP. These fixes can improve the
performances in some cases. Patches can be backported up to v5.6,
v5.11 and v6.7 respectively.
- Patch 7 makes sure 'ss -M' is available when starting MPTCP Join
selftest as it is required for some subtests since v5.18.
- Patch 8 fixes a possible double-free on socket dismantle. The issue
always existed, but was unnoticed because it was not causing any
problem so far. This fix can be backported up to v5.6.
- Patch 9 is a fix for a very recent patch causing lockdep warnings in
subflow diag. The patch causing the regression -- which fixes another
issue present since v5.7 -- should be part of the future v6.8-rc6.
Patch 10 validates the modification, thanks to a new subtest in
diag.sh.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
---
Davide Caratti (1):
mptcp: fix double-free on socket dismantle
Geliang Tang (3):
mptcp: map v4 address to v6 when destroying subflow
selftests: mptcp: rm subflow with v4/v4mapped addr
selftests: mptcp: join: add ss mptcp support check
Matthieu Baerts (NGI0) (1):
mptcp: avoid printing warning once on client side
Paolo Abeni (5):
mptcp: push at DSS boundaries
mptcp: fix snd_wnd initialization for passive socket
mptcp: fix potential wake-up event loss
mptcp: fix possible deadlock in subflow diag
selftests: mptcp: explicitly trigger the listener diag code-path
net/mptcp/diag.c | 3 ++
net/mptcp/options.c | 2 +-
net/mptcp/pm_userspace.c | 10 +++++
net/mptcp/protocol.c | 52 ++++++++++++++++++++++++-
net/mptcp/protocol.h | 21 +++++-----
tools/testing/selftests/net/mptcp/diag.sh | 30 +++++++++++++-
tools/testing/selftests/net/mptcp/mptcp_join.sh | 33 ++++++++++------
tools/testing/selftests/net/mptcp/mptcp_lib.sh | 4 +-
8 files changed, 128 insertions(+), 27 deletions(-)
---
base-commit: b0b1210bc150fbd741b4b9fce8a24541306b40fc
change-id: 20240223-upstream-net-20240223-misc-fixes-1630cd6b3b0a
Best regards,
--
Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
> -----Original Message-----
> From: Larry Finger <Larry.Finger(a)gmail.com>
> Sent: Tuesday, February 27, 2024 9:41 AM
> To: Kalle Valo <kvalo(a)kernel.org>
> Cc: Johannes Berg <johannes(a)sipsolutions.net>; linux-wireless(a)vger.kernel.org; Nick Morrow
> <morrownr(a)gmail.com>; Larry Finger <Larry.Finger(a)lwfinger.net>; stable(a)vger.kernel.org
> Subject: [PATCH] wifi:rtw88: Add missing VID/PIDs
Missing a space between "wifi:" and "rtw88:", and suggest to mention 8811CU
and 8821CU in subject. Others look good to me.
>
> From: Nick Morrow <morrownr(a)gmail.com>
>
> Purpose: Add VID/PIDs that are known to be missing for this driver.
> - removed /* 8811CU */ and /* 8821CU */ as they are redundant
> since the file is specific to those chips.
> - removed /* TOTOLINK A650UA v3 */ as the manufacturer. It has a REALTEK
> VID so it may not be specific to this adapter.
>
> Source is
> https://1EHFQ.trk.elasticemail.com/tracking/click?d=I82H0YR_W_h175Lb3Nkb0D8…
> 0SPxd1Olp3PNJEm7h1Gft8lKFiXqYf1jEjniUnBHTdCi0Ypi2Y9ugy88eGHqb5MB9U0M7ZbBBaOwoaG0eHpd73dxUfRcicgS3TFBvw
> 066sdoIh1JxdrADO_ro60
> Verified and tested.
>
> Signed-off-by: Nick Morrow <morrownr(a)gmail.com>
> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
> Cc: stable(a)vger.kernel.org
Acked-by: Ping-Ke Shih <pkshih(a)realtek.com>
It looks like both 5.15.146 and 5.10.206 are impacted by this regression as they both have the
bad commit 33eae65c6f (smb: client: fix OOB in SMB2_query_info_init()). We tried to
apply the proposed fix eb3e28c1e89b ("smb3: Replace smb2pdu 1-element
arrays with flex-arrays”) but there are a lot of dependencies required to do the backport.
Is it possible to consider the simple fix that Paulo proposed as a solution for 5.10 and 5.15.
We were lucky with 5.4 as it doesn’t have the bad commit because of merge conflict reported
in https://lore.kernel.org/all/2023122857-doubling-crazed-27f4@gregkh/T/#m3aa0…
diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
index 05ff8a457a3d..aed5067661de 100644
--- a/fs/smb/client/smb2pdu.c
+++ b/fs/smb/client/smb2pdu.c
@@ -3556,7 +3556,7 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct TCP_Server_Info *server,
iov[0].iov_base = (char *)req;
/* 1 for Buffer */
- iov[0].iov_len = len;
+ iov[0].iov_len = len - 1;
return 0;
}
Hazem
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: d54e56f31a34fa38fcb5e91df609f9633419a79a
Gitweb: https://git.kernel.org/tip/d54e56f31a34fa38fcb5e91df609f9633419a79a
Author: Breno Leitao <leitao(a)debian.org>
AuthorDate: Wed, 07 Feb 2024 08:52:35 -08:00
Committer: Thomas Gleixner <tglx(a)linutronix.de>
CommitterDate: Mon, 26 Feb 2024 23:41:30 +01:00
x86/nmi: Fix the inverse "in NMI handler" check
Commit 344da544f177 ("x86/nmi: Print reasons why backtrace NMIs are
ignored") creates a super nice framework to diagnose NMIs.
Every time nmi_exc() is called, it increments a per_cpu counter
(nsp->idt_nmi_seq). At its exit, it also increments the same counter. By
reading this counter it can be seen how many times that function was called
(dividing by 2), and, if the function is still being executed, by checking
the idt_nmi_seq's least significant bit.
On the check side (nmi_backtrace_stall_check()), that variable is queried
to check if the NMI is still being executed, but, there is a mistake in the
bitwise operation. That code wants to check if the least significant bit of
the idt_nmi_seq is set or not, but does the opposite, and checks for all
the other bits, which will always be true after the first exc_nmi()
executed successfully.
This appends the misleading string to the dump "(CPU currently in NMI
handler function)"
Fix it by checking the least significant bit, and if it is set, append the
string.
Fixes: 344da544f177 ("x86/nmi: Print reasons why backtrace NMIs are ignored")
Signed-off-by: Breno Leitao <leitao(a)debian.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Paul E. McKenney <paulmck(a)kernel.org>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/20240207165237.1048837-1-leitao@debian.org
---
arch/x86/kernel/nmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index d238679..c95dc1b 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -639,7 +639,7 @@ void nmi_backtrace_stall_check(const struct cpumask *btp)
msgp = nmi_check_stall_msg[idx];
if (nsp->idt_ignored_snap != READ_ONCE(nsp->idt_ignored) && (idx & 0x1))
modp = ", but OK because ignore_nmis was set";
- if (nmi_seq & ~0x1)
+ if (nmi_seq & 0x1)
msghp = " (CPU currently in NMI handler function)";
else if (nsp->idt_nmi_seq_snap + 1 == nmi_seq)
msghp = " (CPU exited one NMI handler function)";
On Mon, Feb 26, 2024 at 05:27:50PM +0200, Радослав Ненчовски wrote:
> Hi. IDK how more clear to write it in the title, so let me explain what the
> problem is.
I'm sending your message to stable instead, because helpdesk is only for
requesting help with kernel.org infrastructure.
Stable folks, please see below.
-K
> In the past 4 or 5 years I've been using this script (with an alias) to
> compress a single folder:
> 7z a "$1.7z" "$1"/ -mx=0 -mmt=8
>
> I know it doesn't look like much but essentially it creates a 7z archive
> (with "store" level of compression) with a name I've entered right after the
> alias. For instance: 7z0 "my dir" will create "my dir.7z".
> And in the past 4 or 5 years this script was working just fine because it
> was recognizing the slash as an indication that the target to compress is a
> directory.
> However, ever since 6.6.17-LTS arrived (altough I've heard the same
> complaints from people who use the regular rolling kernel, but they didn't
> tell me which version) bash stopped recognizing the slash as an indication
> for directory and thinks of it as the entire root directory, thus it
> attempts to compress not only "my dir" but also the whole root (/)
> directory. And it doesn't matter whether I'll put the slash between the
> quotes or outside of them - the result is the same. And, naturally, it
> throws out an unlimited number of errors about "access denied" to everything
> in root. I can't even begin to comprehend why on Earth you or whoever writes
> the kernel would make this change. Forget about me but ALL linux sysadmins I
> know use all kinds of scripts and changing the slash at the end of a word to
> mean "root" instead of a sign for directory is a rude way to ruin their
> work. Since this change occurred, I can no longer put a directory in an
> archive through CLI and I have to do it through GUI, which is about 10 times
> slower. I have a DE and I can do that but what about the sysadmins who
> usually use linux without a DE or directly SSH into the distro they're
> admins of? With this change you're literally hindering their job!
>
> I downgraded the kernel to 6.6.15-LTS and the problem disappeared - now the
> slash is properly recognized as a sign for directory.
>
> The point is: *it is urgent that you undo this change back to the way it
> was! I'm pretty sure sysadmins will begin to email you about this, if they
> haven't already.
> *