On Mon, Apr 10, 2023 at 12:03:34PM -0600, Dave Pifke wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> writes: > > > setsockopt() with SO_SNDBUF never fails: it trims the newbuffsiz that is > > specified by net.core.wmem_max > > Oh, good catch! Your revised patch LGTM, and is closer to what was > being done in the immediately proceeding function, mnl_set_rcvbuffer. > > However, after thinking about it, I feel we should be checking the > receiver value after setsockopt returns. If someone is running > e.g. AppArmor, it seems better to me to attempt the non-privileged > operation first, to avoid adding noise in the logs. > > Also, I don't think there are any current situations where > SO_SNDBUFFORCE might also trim down the value, but after re-reading the > man page, I'm not sure the contract precludes that in the future. > > Attached is a V3 patch for consideration, which also changes the code to > attempt the non-privileged SO_RCVBUF before SO_RCVBUFFORCE. I defer to > your judgment on which version is actually better; I tested both and > they both work a) in a container where SO_SNDBUFFORCE fails, and b) > outside a container with wmem_max set to a small-ish value where > SO_SNDBUFFORCE is required. Thanks for your patch. setsockopt() does not update the &sndnlbuffsiz that is passed as argument in Linux. I have posted this patch: https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230418100223.158964-1-pablo@xxxxxxxxxxxxx/
