Skip to content

[pull] master from torvalds:master #1946

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 11 commits into from
Jun 19, 2025
Merged

[pull] master from torvalds:master #1946

merged 11 commits into from
Jun 19, 2025

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 19, 2025 •
edited
Loading

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

Danilo Krummrich and others added 11 commits June 13, 2025 23:46
rust: completion: implement initial abstraction
1b56e76 
Implement a minimal abstraction for the completion synchronization
primitive.

This initial abstraction only adds complete_all() and
wait_for_completion(), since that is what is required for the subsequent
Devres patch.

Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Juri Lelli <[email protected]>
Cc: Vincent Guittot <[email protected]>
Cc: Dietmar Eggemann <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Ben Segall <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Valentin Schneider <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
rust: revocable: indicate whether data has been revoked already
4b76faf 
Return a boolean from Revocable::revoke() and Revocable::revoke_nosync()
to indicate whether the data has been revoked already.

Return true if the data hasn't been revoked yet (i.e. this call revoked
the data), false otherwise.

This is required by Devres in order to synchronize the completion of the
revoke process.

Reviewed-by: Benno Lossin <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
rust: devres: fix race in Devres::drop()
f744201 
In Devres::drop() we first remove the devres action and then drop the
wrapped device resource.

The design goal is to give the owner of a Devres object control over when
the device resource is dropped, but limit the overall scope to the
corresponding device being bound to a driver.

However, there's a race that was introduced with commit 8ff6566
("rust: devres: remove action in `Devres::drop`"), but also has been
(partially) present from the initial version on.

In Devres::drop(), the devres action is removed successfully and
subsequently the destructor of the wrapped device resource runs.
However, there is no guarantee that the destructor of the wrapped device
resource completes before the driver core is done unbinding the
corresponding device.

If in Devres::drop(), the devres action can't be removed, it means that
the devres callback has been executed already, or is still running
concurrently. In case of the latter, either Devres::drop() wins revoking
the Revocable or the devres callback wins revoking the Revocable. If
Devres::drop() wins, we (again) have no guarantee that the destructor of
the wrapped device resource completes before the driver core is done
unbinding the corresponding device.

CPU0					CPU1
------------------------------------------------------------------------
Devres::drop() {			Devres::devres_callback() {
   self.data.revoke() {			   this.data.revoke() {
      is_available.swap() == true
					      is_available.swap == false
					   }
					}

					// [...]
					// device fully unbound
      drop_in_place() {
         // release device resource
      }
   }
}

Depending on the specific device resource, this can potentially lead to
user-after-free bugs.

In order to fix this, implement the following logic.

In the devres callback, we're always good when we get to revoke the
device resource ourselves, i.e. Revocable::revoke() returns true.

If Revocable::revoke() returns false, it means that Devres::drop(),
concurrently, already drops the device resource and we have to wait for
Devres::drop() to signal that it finished dropping the device resource.

Note that if we hit the case where we need to wait for the completion of
Devres::drop() in the devres callback, it means that we're actually
racing with a concurrent Devres::drop() call, which already started
revoking the device resource for us. This is rather unlikely and means
that the concurrent Devres::drop() already started doing our work and we
just need to wait for it to complete it for us. Hence, there should not
be any additional overhead from that.

(Actually, for now it's even better if Devres::drop() does the work for
us, since it can bypass the synchronize_rcu() call implied by
Revocable::revoke(), but this goes away anyways once I get to implement
the split devres callback approach, which allows us to first flip the
atomics of all registered Devres objects of a certain device, execute a
single synchronize_rcu() and then drop all revocable objects.)

In Devres::drop() we try to revoke the device resource. If that is *not*
successful, it means that the devres callback already did and we're good.

Otherwise, we try to remove the devres action, which, if successful,
means that we're good, since the device resource has just been revoked
by us *before* we removed the devres action successfully.

If the devres action could not be removed, it means that the devres
callback must be running concurrently, hence we signal that the device
resource has been revoked by us, using the completion.

This makes it safe to drop a Devres object from any task and at any point
of time, which is one of the design goals.

Fixes: 76c01de ("rust: add devres abstraction")
Reported-by: Alice Ryhl <[email protected]>
Closes: https://lore.kernel.org/lkml/[email protected]/
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
rust: devres: do not dereference to the internal Revocable
20c96ed 
We can't expose direct access to the internal Revocable, since this
allows users to directly revoke the internal Revocable without Devres
having the chance to synchronize with the devres callback -- we have to
guarantee that the internal Revocable has been fully revoked before
the device is fully unbound.

Hence, remove the corresponding Deref implementation and, instead,
provide indirect accessors for the internal Revocable.

Note that we can still support Devres::revoke() by implementing the
required synchronization (which would be almost identical to the
synchronization in Devres::drop()).

Fixes: 76c01de ("rust: add devres abstraction")
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
mailmap: add entry for Danilo Krummrich
b8b8663 
Add an entry to remap my Red Hat address.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
@namjaejeon
ksmbd: add free_transport ops in ksmbd connection
a89f5fa 
free_transport function for tcp connection can be called from smbdirect.
It will cause kernel oops. This patch add free_transport ops in ksmbd
connection, and add each free_transports for tcp and smbdirect.

Fixes: 21a4e47 ("ksmbd: fix use-after-free in __smb2_lease_break_noti()")
Reviewed-by: Stefan Metzmacher <[email protected]>
Signed-off-by: Namjae Jeon <[email protected]>
Signed-off-by: Steve French <[email protected]>
@namjaejeon
ksmbd: fix null pointer dereference in destroy_previous_session
7ac5b66 
If client set ->PreviousSessionId on kerberos session setup stage,
NULL pointer dereference error will happen. Since sess->user is not
set yet, It can pass the user argument as NULL to destroy_previous_session.
sess->user will be set in ksmbd_krb5_authenticate(). So this patch move
calling destroy_previous_session() after ksmbd_krb5_authenticate().

Cc: [email protected]
Reported-by: [email protected] # ZDI-CAN-27391
Signed-off-by: Namjae Jeon <[email protected]>
Signed-off-by: Steve French <[email protected]>
@namjaejeon
ksmbd: handle set/get info file for streamed file
4ea0bb8 
The bug only appears when:
 - windows 11 copies a file that has an alternate data stream
 - streams_xattr is enabled on the share configuration.

Microsoft Edge adds a ZoneIdentifier data stream containing the URL
for files it downloads.

Another way to create a test file:
 - open cmd.exe
 - echo "hello from default data stream" > hello.txt
 - echo "hello again from ads" > hello.txt:ads.txt

If you open the file using notepad, we'll see the first message.
If you run "notepad hello.txt:ads.txt" in cmd.exe, we should see
the second message.

dir /s /r should least all streams for the file.

The truncation happens because the windows 11 client sends
a SetInfo/EndOfFile message on the ADS, but it is instead applied
on the main file, because we don't check fp->stream.

When receiving set/get info file for a stream file, Change to process
requests using stream position and size.
Truncate is unnecessary for stream files, so we skip
set_file_allocation_info and set_end_of_file_info operations.

Reported-by: Marios Makassikis <[email protected]>
Signed-off-by: Namjae Jeon <[email protected]>
Signed-off-by: Steve French <[email protected]>
@maddy-kerneldev @gregkh
Documentation: embargoed-hardware-issues.rst: Add myself for Power
eab9dcb 
Adding myself as the contact for Power

Signed-off-by: Madhavan Srinivasan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
@torvalds
Merge tag 'driver-core-6.16-rc3' of git://git.kernel.org/pub/scm/linu…
229f135 
…x/kernel/git/driver-core/driver-core

Pull driver core fixes from Danilo Krummrich:

 - Fix a race condition in Devres::drop(). This depends on two other
   patches:
     - (Minimal) Rust abstractions for struct completion
     - Let Revocable indicate whether its data is already being revoked

 - Fix Devres to avoid exposing the internal Revocable

 - Add .mailmap entry for Danilo Krummrich

 - Add Madhavan Srinivasan to embargoed-hardware-issues.rst

* tag 'driver-core-6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core:
  Documentation: embargoed-hardware-issues.rst: Add myself for Power
  mailmap: add entry for Danilo Krummrich
  rust: devres: do not dereference to the internal Revocable
  rust: devres: fix race in Devres::drop()
  rust: revocable: indicate whether `data` has been revoked already
  rust: completion: implement initial abstraction
@torvalds
Merge tag '6.16-rc2-ksmbd-server-fixes' of git://git.samba.org/ksmbd
fb4d33a 
Pull smb server fixes from Steve French:

 - Fix alternate data streams bug

 - Important fix for null pointer deref with Kerberos authentication

 - Fix oops in smbdirect (RDMA) in free_transport

* tag '6.16-rc2-ksmbd-server-fixes' of git://git.samba.org/ksmbd:
  ksmbd: handle set/get info file for streamed file
  ksmbd: fix null pointer dereference in destroy_previous_session
  ksmbd: add free_transport ops in ksmbd connection
@pull pull bot added the ⤵️ pull label Jun 19, 2025
@pull pull bot merged commit fb4d33a into AwesomeGitHubRepos:master Jun 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
⤵️ pull
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@namjaejeon @maddy-kerneldev @torvalds